Add a Talks Manager permissions group

[jrrickerson]

Create a fixture or migration that creates a new user group for talk managers. This will allow superuser administrators to allow access by other users to manage the talks schedule without giving full superuser status to those users.

This group should have the following permissions:

• Staff permission (for admin login)
• Full permission to Talk model
• Full permission to Session model

This group should NOT have:

• Superuser status
• Any access to the Group model
• Any access to the User model

[parkerhancock]

Hey! I've been looking into this, and it might be worth rethinking the Staff Permission piece.

The permissions for Talk and Session are pretty easy to add to a migration, but "staff" status is a field directly on the User model, and not a permission.

My current (not working) approach is to add a proxy model to the User with a custom permission, add that permission to the talk manager group, and then set up a pre_save signal on User to switch the "is_staff" attribute on a user if it sees the custom permission.

It's roundabout, but in theory should work.

[parkerhancock]

The usual source doesn't have a good easy answer.

Stack Overflow - Staff based on Group

Also, I'm relatively certain that the suggested answers there won't work - although if there was a way to override the "is_staff" model attribute with a dynamic property (via @Property) that checks for a custom permission, that might be more straightforward. Not quite sure how to do that yet.

[jrrickerson]

There may be a simpler method to achieve this, I think.
If the Group itself is created with the basic model permissions, that will have everything except the is_staff flag set for that user. Of course since they're already adding the person to the Group, the admin could simply manually set the is_staff flag, but that's not a great solution.
However, since the User and Group have a Many to Many relationship, adding a user to a group necessitates the creation of a User_group intermediate model. If we hook a post_save signal to that model, we should be able to examine which group was being added, and set that user's is_staff flag at that point.
I think that should eliminate the need for a proxy model. What do you think @parkerhancock?

[parkerhancock]

I agree that just manually setting "is_staff" is not a good solution. And I like the idea of avoiding having to create a proxy model.

My only addition would be I think the signal handler would need to listen to the m2m_changed signal. I don't know offhand whether the Admin app uses the 'add' method, but using m2m_changed should work either way.

From the docs:

"Using add() with a many-to-many relationship, however, will not call any save() methods, but rather create the relationships using QuerySet.bulk_create(). If you need to execute some custom logic when a relationship is created, listen to the m2m_changed signal." link

Also, I'm not sure how to import the implicit intermediate model, but I have confidence I can figure that one out.

I'll give it a shot this week and see what happens.

Thanks!