Re: Adding several user models

When you say 'share the database', are you referring to the same database server but separate database instances? Or are you expecting both projects to access the same tables in the same database instance? 

It will be the same tables in the same database instance. 

You like to live dangerously don't you? ;-)

That fact actually changes my perspective quite a bit. Typically with separate but integrated projects, one project holds the actual user data, and the other keeps a copy of a minimal subset of meta data, enough to identify the user in the other application when necessary. That was my assumption for my original response.

If they share the same underlying table, then they'll definitely need to be in sync, and I would definitely recommend having a common model definition between the two projects. You should probably pick one of the projects as the 'master' where the migrations for that project will handle the Participants table, and the other project model will be marked as unmanaged to avoid migrations being needed. The likely candidate is the Participants project since it has the more complicated functionality associated with its user model.

 

All of those issues aside, I wouldn't start with an abstract model inheriting from AbstractUser. I would create a clean abstract model inheriting from models.Model, and copy everything from AbstractUser over to your new abstract user model. Your Admin project would then define a concrete user model that inherits directly from your new abstract user model. Over in the Participant project, your concrete model would inherit from the abstract model created in the Admin project, and also from AbstractBaseUser and the PermissionsMixin, just like AbstractUser does. This way, you have a single model controlling what fields are made available in both applications, but only the Participant project model contains the extra machinery to use that model to authenticate/authorize users. The copy/paste operation probably violates DRY for some purists, but you'll likely be modifying those fields at some point anyway, so I consider it a necessary evil. 

I agree with this setup - however I would like more fine grained permissions in the admin project.

Sure, but having the models set up in such a way shouldn't prevent that. The Participant objects are not real end users in that context (or at least, I'm assuming they can't log in), just regular models, so they won't need permissions assigned to them. It would be a combination of assigning correct permissions to your Admin users and filtering the views and serializers appropriately.

-James

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Be%2BciWFK6sEHq45Ep3ijNix44_mv9xaE0_uhR2XzHdVq16zWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.