Question

I am using Djangos default authentication system (django.contrib.auth) and I would like to add ‘roles’ to my users in such a way that Django Admin can work with it.

An example:

• A user can be a staffmember, teacher, student and/or parent
• If the user has a role assigned, he will gain permissions (eg. staffmembers may sign in to the Django admin)
• Some roles might have some extra fields (eg. parent has a relation with at least one student and each student has a field with it’s classgroup
• Not every role has extra fields
• A parent can be a teacher or staffmember and vise versa
• A student can not have another role

There are all sorts of (conventional) ways to accomplish the above within a model. Django supports a lot of them, but the Django admin does not. The Django admin has a lot of good features so I would like to use it (but I am getting more and more afraid that it will not be possible).

The following model is what I thought of at first:

class ExtendedUser(contrib.auth.models.User):
    """
       For the ease of use I inherit from User. I might
       want to add methods later
    """
    pass

class StaffMember(models.Model):
    """
       A staffmember is a co-worker of the organisation
       and has permissions to make changes to (parts of)
       the system.

       For now the staffmember only has methods
    """
    user = models.OneToOneField(ExtendedUser, related_name="staff_member")

class Student(models.Model):
    """
      A student can participate in some courses
    """
    user = models.OneToOneField(ExtendedUser, related_name="student")

class Teacher(models.Model):
   user = models.OneToOneField(ExtendedUser, related_name="teacher")
   subjects = models.ManyToManyField(..)

class Parent(models.Model):
    user = models.OneToOneField(ExtendedUser, related_name="parent")
    children = models.ManyToManyField(Student, related_name=parents")

This works in Django (and in a lot of other MVC-based frameworks). But I can’t find a proper way to display the above in the admin.

Ideally I would like to add a User and then within the User-changeview add different roles. At first I thought I could use Inlines:

class StudentInlineAdmin(admin.StackedInline):
    model = Student
    extra = 0
    template = 'accounts/admin/role.html'

I then make some slight changes to the inline template to present the editing user button with a caption ‘Add Student role’. Once we hit the button, we display the form and a User role is added. Not ideal, but it works.

Too bad, for Staffmembers there are no fields to add to the inline form. This way it is not possible to trigger the ‘has_changed’ property for inlines forms. This results in the new role not being saved to the database.

To solve this last problem, I hacked around a bit and added a ‘dummy’ formfield to the empty user-roles and then hide this field using JS. This did trigger the has_changed.

Still this would not work for somehow none of my inline-models are saved during some tests later on.

So I think I am just doing it the wrong way. I did a lot of Googling and found a lot of people hassling with the same sorts of problems. The one that suited my situation the most was http://www.mail-archive.com/[e-mail]/msg52867.html. But still this solution does not give me an easy way to implement the admin.

I also thought about using the built-in groups but in that case I have no idea how I should add the different fields.

Another thing I thought of was trying to ‘Add a student’ instead of adding a User and assigning a role to him. This works pretty well in the admin if you just inherit the user:

class StudentUser(auth.models.User):
  pass

But two problems here. At first it is not possible to be a staffmember and a teacher. Second it is not really working in the rest of Django for the request object return a User object for which it is impossible to request the Student, Parent, Staffmember object. The only way to get one of these is to instantiate a new Student object bases on the User object.

So here is the question: what type of model design should I use to add roles to Users in such a way that it works in Django and in the Django admin?

Friendly Regards,
Wout

Answer 1

I’m assuming in the following that you do not want to alter the admin, or make a copy of django.contrib.admin and hack it as desired.

A user can be a staffmember, teacher, student and/or parent

You could store this in a user profile. Inheriting from User will work, too, but instead of using User.get_profile(), you’ll need to manually map from User to ExtendedUser.

If the user has a role assigned, he will gain permissions (eg. staffmembers may sign in to the Django admin)

In that specific case, you can’t use automatic role-based assignment. Whether or not a person can access the admin is determined by the is_staff field in their User record.

The most automatic way I can think of is to create an "Update Permissions" admin command, which will update admin fields like is_staff and the permissions based on the role set in the user’s profile. BTW, even though this is not fully "automatic", it is a denormalization that can improve performance.

Some roles might have some extra fields (eg. parent has a relation with at least one student and each student has a field with it’s classgroup

Not every role has extra fields

A parent can be a teacher or staffmember and vise versa

A student can not have another role

Read up on form validation. That’s where you can enforce these rules.

In your model, I’d recommend that you alter the related names of your one-to-one fields:

class StaffMember(models.Model):
    user = models.OneToOneField(ExtendedUser, related_name="as_staff_member")

class Student(models.Model):
    user = models.OneToOneField(ExtendedUser, related_name="as_student")

class Teacher(models.Model):
    user = models.OneToOneField(ExtendedUser, related_name="as_teacher")

class Parent(models.Model):
    user = models.OneToOneField(ExtendedUser, related_name="as_parent")

Since theUser.as_teacher is a lot clearer than theUser.teacher (which I would read as "the user’s teacher").

This works in Django (and in a lot of other MVC-based frameworks). But I can’t find a proper way to display the above in the admin.

You’re going to have one table in the admin per role. There’s no fancy "bottom half of the edit page will redraw itself when you change roles" feature. If you want that, you will need to write your own admin.

Django’s admin is great, but it’s not trying to be everything to everyone. I have a role-based setup like yours (except the roles themselves are stored in a table), and the admin works fine if a little clunky. The general idea is that if the admin isn’t good enough, then you should be writing your own views.

I also thought about using the built-in groups but in that case I have no idea how I should add the different fields.

The built-in groups are not what you’re looking for.

Another thing I thought of was trying to ‘Add a student’ instead of adding a User and assigning a role to him. […] At first it is not possible to be a staffmember and a teacher.

"Subclassing" is a more restrictive one-to-one. I think your initial model is better.

Second it is not really working in the rest of Django for the request object return a User object for which it is impossible to request the Student, Parent, Staffmember object. The only way to get one of these is to instantiate a new Student object bases on the User object.

No, you instead find the Student object using the auto-generated id from the User object:

try:
   theStudent = Student.objects.get(user_ptr_id=theUser.id)
except Student.DoesNotExist:
   # That user isn't a student; deal with it here.

If you’re going to use the admin, I think you’re going to have to live with a two-step process of adding an ExtendedUser, then adding Student or whatever entries for them.

So it comes down to a tradeoff: a little extra work using the built-in admin, or writing your own user management views. WHich route is best really depends on how much this interface will be used: If it’s just you, then the admin should be fine, even with its warts. If a lot of people will be using it on a routine basis, then you should just write your own views to handle things.