On Wed, Jan 28, 2015 at 3:00 PM, 詹上潁 <[email protected]> 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 [email protected]. To post to this group, send email to [email protected]. 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. For more options, visit https://groups.google.com/d/optout.
