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:>> wrote: > > > > 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 > > < > 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 > > > > -- > > 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 > > <javascript:>. > > To post to this group, send email to > > django...@googlegroups.com <javascript:>. > > Visit this group at > > https://groups.google.com/group/django-users > > <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 > > < > https://groups.google.com/d/msgid/django-users/1678108.SszHfPmntC%40devstation > >. > > For more options, visit https://groups.google.com/d/optout > > <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+unsubscr...@googlegroups.com > > <mailto:django-users+unsubscr...@googlegroups.com>. > > To post to this group, send email to django-users@googlegroups.com > > <mailto: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/78232020-3361-4284-afa1-7a0a6f94efcf%40googlegroups.com > > < > https://groups.google.com/d/msgid/django-users/78232020-3361-4284-afa1-7a0a6f94efcf%40googlegroups.com?utm_medium=email&utm_source=footer > >. > > 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+unsubscr...@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/CAMnnoUK47UUVVwvW8PjzZ4hRf8WuQf%3DpNiqXqste9xPYyWh0dQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
