On Wed, Jan 28, 2015 at 9:32 PM, Andreas Kuhne <andreas.ku...@suitopia.com> wrote:
> 2015-01-28 13:26 GMT+01:00 Russell Keith-Magee <russ...@keith-magee.com>: > >> >> On Wed, Jan 28, 2015 at 3:00 PM, 詹上潁 <boy801...@gmail.com> wrote: >> >>> My project need an admin for staff and a normal website for normal user. >>> Staff can only login to staffsite and normal user can only login to >>> website. Staff will login to admin to do some management. They can >>> view normal user list and detail and create or delete normal user >>> admin. The two type of user is very different, so I want to write a model >>> for each of them, instead of using is_staff flag. But in a project, I can >>> only have a USER_AUTH_MODEL. Is there a good way to implement these >>> requirements? >>> >>> Since a project can only have a USER_AUTH_MODEL, I separate the two type >>> of user in two project (staffsite and website). >>> My currently design and implementation is as follow: >>> >>> I wrote a standalone django app called member, and implement Member model >>> >>> class Member(AbstractBaseUser): >>> #member related fields >>> >>> then I create two project “staffsite" and “website". “staffsite" is for >>> internal use, “website" is open for normal user. “staffsite" just use the >>> django built in auth.User. Member model in “staffsite" is just a normal >>> model. “website" use Member model as USER_AUTH_MODEL. >>> I have two database, one for “staffsite" and one for “website". Since >>> “staffsite" need to access Member’s data, so I implement a db router for >>> “staffsite". Whenever I need to access Member’s data in >>> “staffsite", router will route me to the correct db (You can say that I >>> use db to link “staffsite” and “website” together.) >>> member app need to install in both “staffsite" and “website", so I >>> will have two copy of member app. This is not good for >>> maintenance. Whenever I change the code in member app, I need to copy and >>> paste to another one. I extract member app and create a standalone app, and >>> after that I can use pip install -e to install member app for >>> both project and I only have to keep one copy of code. >>> >>> This design is work, but I want to know whether there is a better way to >>> meet the requirements. >>> >> >> Yes, this approach will work. It might be the best approach if you really >> do have 2 completely different sites (even different URLs) that share a >> little bit of data. >> >> However, if you've got a single site that just has 2 different types of >> users, an approach that might be easier to manage is write a common "user" >> model, and then have different profiles for Admin and Normal users. >> >> This captures the idea that a User isn't something that contains >> specialised information - it's purely a container to hold a username and >> password. Once a user has logged in, if there is specialist information >> needed, then you put that information onto a profile model that has a >> foreign key to the user model. >> >> Think of it this way - regardless of whether someone is an staff member >> or a normal user, they're still a person. The User model should be >> capturing the fact that they're a person; then, you build other data models >> to store information about their other roles. >> >> The added advantage of this approach is that a single User can be both an >> Staff member and a Regular user, as needed - because they have a single >> User, but 2 different profiles. >> >> I hope this helps. >> >> Yours >> Russ Magee %-) >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-users+unsubscr...@googlegroups.com. >> To post to this group, send email to django-users@googlegroups.com. >> Visit this group at http://groups.google.com/group/django-users. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-users/CAJxq848vK8wqX6viT2mdkz4chcP3MfjOq7mceH%2Bss_9S3dWmXA%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-users/CAJxq848vK8wqX6viT2mdkz4chcP3MfjOq7mceH%2Bss_9S3dWmXA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > I'll be facing the exact same problems with a site I am developing at the > moment. > > Russ, your solution isn't that for the old user profile way of thinking, > that is deprecated today (user.get_profile())? Or are you using the same > idea in a different way? > The bit that was deprecated was the USER_PROFILE_MODEL setting and User.get_profile() support method. It turns out that once we sorted out retrieval and storage of ForeignKey/OneToOnFields, get_profile() was redundant - the behavior it implemented happens automatically on *every* relation without needing a specialist method. However, the *pattern* of having profile models hasn't been deprecated - it's even explicitly suggested in the docs: https://docs.djangoproject.com/en/1.7/topics/auth/customizing/#specifying-a-custom-user-model Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAJxq848G%3Ddgg5eLyQNka6G_eCS%2BheRrnG4Guh0sW-d8-o8AfPg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
