Multiple roles per user#591

Currently, we can only assign one role to a user and one role only, i. e. editor.
However, permissions in real-life are often more fine-grained:

• Only specific users should be allowed to edit events
• Only specific users should be allowed to edit news
• Only specific users should be allowed to add new users

Hence, it would provide for much more flexibility, when we could add more than one role per user. One could define news_editor, event_editor, user_manager roles with different permissions.

A user who can do all these things simply gets all the roles assigned. A user who can do just one thing, only gets one role assigned.

This won’t be easy, but let’s try to spell out a few more things at least:

How are conflicting permissions resolved? news_editor can do action a but not B, event_editor cannot do A but B. What happens if both get assigned to one user?

I would say it should behave like this:

• In general, permissions are cumulative. So if any one of the user’s roles allows an action and the other role(s) don’t explicitly disallow the action, the user is allowed the action.
• If one role allows the action and another explicitly disallows the action, we could have an order-based system. Either the order could be defined globally via the config or we would allow changing the role order per user. The role listed before another will then always win the conflict.

There are certainly more edge cases here, e.g. how to interpret the wildcard * permission definition.

Thanks for your comments.

Roles should work in a cascade, applied in the order of how they were assigned.

The given example for conflicting permissions is not really an issue: If news_editor needs permission A for their task and event_editor needs permission B, any user that combines both roles obviously needs both permissions. If these permissions exclude each other, the flaw is in your role organisation.

However one could reduce the overhead by choosing a opt-in only strategy: You may only give permissions, rather than explicitly be able to take them away. It is also easier UI-wise.

Only supporting an opt-in strategy indeed sounds sensible as it reduces the complexity by a lot. The order of the roles does not matter then as there cannot be any conflicts. It would also not be a breaking change as the current behavior is already “can role X do Y”. The new behavior would be “can any of the assigned roles do Y”. Edge cases in the interaction of different roles (depending on the site setup) can still be solved via custom hooks.