Canonical way of handling multiple types of users? (Profiles vs subclassing django.contrib.auth.models.AbstractUser)

826 views
Skip to first unread message

Victor Hooi

unread,
Nov 9, 2016, 12:54:43 AM11/9/16
to Django users
Hi,

What is the current canonical way to handle multiple user-profiles in Django?

For example - say you have "Teachers", "Students", "Parents" - you may have slightly different fields for each one and/or different behaviour. Students will have things like grades, Parents may have 1-to-many Students etc.

I understand you can use a OneToOne field to associated different user profiles with each type of user:


The docs mention using a django.db.models.signals.post_save signal on User, but I'm guessing that won't work here if you have multiple types of users.

Or are you better off subclassing django.contrib.auth.models.AbstractUser? (I get the impression using profile models is less invasive).

Regards,
Victor

Mike Dewhirst

unread,
Nov 9, 2016, 3:22:57 AM11/9/16
to django...@googlegroups.com
On 9/11/2016 11:54 AM, Victor Hooi wrote:
> Hi,
>
> What is the current canonical way to handle multiple user-profiles in
> Django?
>
> For example - say you have "Teachers", "Students", "Parents" - you may
> have slightly different fields for each one and/or different
> behaviour. Students will have things like grades, Parents may have
> 1-to-many Students etc.
>
> I understand you can use a OneToOne field to associated different user
> profiles with each type of user:

If a Parent is also a Teacher then you would need two profiles for that
parent. Personally, I like profiles in a OneToOne relationship with the
user (or custom user) model but for different sets of characteristics I
would use multiple tables and make each of them OneToOne with user.

If they were somewhat similar I would separate out all the common fields
and methods and make an abstract CoreFields model and inherit that in
each of the different profile models. For example
StudentProfile(CoreFields), TeacherProfile(CoreFields)
ParentProfile(CoreFields) and so on. That would let you have more than
one profile per user.

I'm not sure about canonical in this context. The zen of python is
probably your best guide.

Mike

>
> https://docs.djangoproject.com/en/1.10/topics/auth/customizing/#extending-the-existing-user-model
>
> The docs mention using a django.db.models.signals.post_save
> <https://docs.djangoproject.com/en/1.10/ref/signals/#django.db.models.signals.post_save>
> signal on User, but I'm guessing that won't work here if you have
> multiple types of users.
>
> Or are you better off subclassing
> django.contrib.auth.models.AbstractUser? (I get the impression using
> profile models is less invasive).
>
> Regards,
> Victor
> --
> 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...@googlegroups.com
> <mailto:django-users...@googlegroups.com>.
> To post to this group, send email to django...@googlegroups.com
> <mailto:django...@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/314de801-0ca7-4eb3-abb9-7a3044994bcd%40googlegroups.com
> <https://groups.google.com/d/msgid/django-users/314de801-0ca7-4eb3-abb9-7a3044994bcd%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

Melvyn Sopacua

unread,
Nov 9, 2016, 9:37:23 AM11/9/16
to django...@googlegroups.com
Hi,

> What is the current canonical way to handle multiple user-profiles in
> Django?

it highly depends on how you see these objects:

1. different types of users (requirement: a user can only be one type)
2. one type of user with additional information from different sources
3. different types of users, but users can be multiple types

Obviously the third is the hardest.


On Tuesday 08 November 2016 16:54:43 Victor Hooi wrote:

> For example - say you have "Teachers", "Students", "Parents" - you may
> have slightly different fields for each one and/or different
> behaviour. Students will have things like grades, Parents may have
> 1-to-many Students etc.

Here you clearly think of them as types, instead of Humans and yet they
can fulfill multiple roles. It also doesn't matter what is in the
profile, as long as you don't care about enforcing required information
at the model layer.
You can make one profile model with the union of all fields and use
group membership to enforce requirements. So a Human which is member of
the Teachers group must have "date_employed" filled in while Student
must have "date_enrolled". Similarly, you can use group membership to
determine what information to show.
Splitting them out in different profiles is a matter of preference and
optimization, not of design.

> The docs mention using a django.db.models.signals.post_save
> <https://docs.djangoproject.com/en/1.10/ref/signals/#django.db.models.
> signals.post_save> signal on User, but I'm guessing that won't work
> here if you have multiple types of users.

When you have multiple *profiles* this will work just fine. It's also
not a big problem to solve, because user creation and updating is not an
uncontrollable process like the docs suggest.
User creation via commandline or automated process really only happens
in tests and backup restore procedures.

In production it's your job to properly set permissions for meddling
with users in the admin and to provide forms that include relevant
profile information. When providing good forms the signal is actually
disruptive: you already have the information available, you save the
user then save the profile information. Having a signal fire that
doesn't have access to that profile information is not very useful and
can lead to validation errors simply because the handler doesn't have
the context.

> Or are you better off subclassing
> django.contrib.auth.models.AbstractUser? (I get the impression using
> profile models is less invasive).

The case for subclassing is really only one:
Do you not have the right information in the standard user model to
authenticate the user?
Highly specialized cases aside, it's better to use profiles.

A prominent example for not having the right information is when
authentication happens with SSL certificates rather then
username/password. Another is having different authentication servers
and what server to use is depending on a field that isn't in the user
model, like "faculty" or "signup_date.year".

Hope this helps,
--
Melvyn Sopacua

Vineet Kothari

unread,
Nov 13, 2016, 5:57:53 PM11/13/16
to django...@googlegroups.com
Use one to many field or many to many field

--
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...@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/1678108.SszHfPmntC%40devstation.

Victor Hooi

unread,
Jun 14, 2017, 10:59:37 AM6/14/17
to Django users
Resurrecting a slightly old thread =), but coming back to this project.

Say I have multiple models that each have their own user profile. 

Let's assume that each type of user is mutually exclusive (i.e. a student cannot be a teacher etc.)

class Student(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE)
 
class Teacher(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE) 
 
class Parent(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE)

How do you use the Django Admin to manage multiple types of users?

The docs mention adding an inline to UserAdmin - however, this seems to assume you only have one model with a user profile - what if you have multiple?

Regards,
Victor
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.

Victor Hooi

unread,
Jun 19, 2017, 4:45:26 AM6/19/17
to Mike Dewhirst, django...@googlegroups.com
Aha, thanks for the good points.

I could go down the route of using auth.groups.

I'd still need a user profile to store the additional fields - are you thinking I should only have a single Profile class, and make all the fields nullable?

The issue though is still - how do I integrate this with Google Admin well? Ideally we'd want different sections to edit teachers, vs students vs parents - but not sure if this is possible.

On Wed, 14 Jun 2017 at 21:45 Mike Dewhirst <mi...@dewhirst.com.au> wrote:
On 14/06/2017 8:59 PM, Victor Hooi wrote:
> Resurrecting a slightly old thread =), but coming back to this project.
>
> Say I have multiple models that each have their own user profile.
>
> Let's assume that each type of user is mutually exclusive (i.e. a
> student cannot be a teacher etc.)

IMO that's a problematic assumption. It is usually best to model real
life and if you take simplifying shortcuts (i.e. a student cannot be a
teacher etc.) which don't work out in practice for any reason you end up
with a project which has to turn itself inside out to keep working.

For me, the "canonical way" would be to use roles. By that I mean
auth.groups.

I have been bitten before and learned long ago that assumptions related
to people and what they do/are can be plain wrong.

I would be assuming that a student could also be a teacher. And vice
versa. And simultaneously! And there's nothing outrageous in that.
Students often become teachers and as tutors can fill both roles at once.

auth.groups let's you do all sorts of things including role reversals
and dual roles. You might need object permissions as well if you have
information silos so that being in a teacher role for one should not
give unfettered access to a different silo accessed as a student.

In any case, such an approach is usually simpler than software which
deviates from reality.

That'll be 2c

Mike


>
>     class Student(models.Model):
>         user = models.OneToOneField(User, on_delete=models.CASCADE)
>
>     class Teacher(models.Model):
>         user = models.OneToOneField(User, on_delete=models.CASCADE)
>
>     class Parent(models.Model):
>         user = models.OneToOneField(User, on_delete=models.CASCADE)
>
>
> How do you use the Django Admin to manage multiple types of users?
>
> The docs mention adding an inline to UserAdmin - however, this seems
> to assume you only have one model with a user profile - what if you
> have multiple?
>
> Regards,
> Victor
>
> On Monday, 14 November 2016 04:57:53 UTC+11, me.vineetkothari wrote:
>
>     Use one to many field or many to many field
>
>     On Wed, Nov 9, 2016 at 3:06 PM, Melvyn Sopacua <m.r.s...@gmail.com
>         <javascript:>.

>         To post to this group, send email to
>         django...@googlegroups.com <javascript:>.

>         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/1678108.SszHfPmntC%40devstation

>         For more options, visit https://groups.google.com/d/optout

>
>
> --
> 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...@googlegroups.com

> To post to this group, send email to django...@googlegroups.com

> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
Reply all
Reply to author
Forward
0 new messages