Lately, I have been looking at using subclasses of auth.User as a way of segmenting users.
This appears (to me, at this stage, anyway) to have several advantages over using the UserProfile approach. * You can have extra attributes on the subclass. For instance, one set of users belong to a Company, and I can do this FK relation from the subclass. Similarly, I can have a date_of_birth field that is attached to the user, rather than the UserProfile. From a performance perspective, this doesn't make a lick of difference, as a subclass of a concrete class still has a join anyway. * You can easily have different user classes appear differently in the admin. * You can have different relationships between particular User types and other objects. For instance, a Staff user may 'work_at' a Location, but an 'AreaManager' may have a 'manages' relationship to an Area. You can still do this with auth.User, but every user will have every relationship. The biggest helper for this was to have an authentication backend that automatically selects the subclass, so that you no longer get a User object in request.user, but whatever you want. A drawback is that you can't easily change the field types: email, which I use for authentication, needs to be unique. You can handle this with validation checking on forms, but that requires you to remember to build this into your forms. The other way is to monkey-patch the User class directly, and manually fix the database to not allow duplicates on the email column. -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/Y6qCTdPzU9sJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
