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 -- 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/1678108.SszHfPmntC%40devstation. For more options, visit https://groups.google.com/d/optout.
