Allow multiple roles to be assigned via the admin UI

[galbaras]

WordPress currently only allows the assignment of one role to a user and the default roles are organized hierarchically, with each one being a superset of the next, up to the almighty administrator role.

However, development is only possible for administrators, so there is no role that allows operational administration (user management, comment approval, etc), but no development capabilities, (theme settings, widgets, plugins, custom CSS, etc).

I think there is a need to separate these things, and the best way to do this is to create a "Developer" role, and perhaps a "Customizer" role, which can be assigned to certain administrators. Since presentation capabilities are on a different dimension from content/operation capabilities, there is a need to assign them to users in parallel.

For example, the proposal for custom CSS in the customizer introduces a way for people who don't know what they're doing to cause display problems. By assigning to them a role that allows operational administration, but no development capabilities, this function can be reserved for the knowledgeable users only.

Allowing multiple role assignment may be a big change, but it's likely to be useful to many people, because without it, professionally supported sites end up giving client employees more power than they should have.

I know there are plugins for these things, but I think they should be in core, and leave the plugins to handle uncommon situations.

[jdgrimes]

Replying to galbaras:

WordPress currently only allows the assignment of one role to a user and the default roles are organized hierarchically, with each one being a superset of the next, up to the almighty administrator role.

For clarity, I'd like to note that this is a purely user-facing restriction. The underlying code all supports assigning multiple roles to users, that feature simply isn't provided through the UI.

[galbaras]

Well, that should make things a lot easier, then :) Adding the UI focus.

[johnbillion]

Allowing multiple roles is very useful, but I don't think that a UI in core makes sense for just the reasons you listed above. Core's default roles are effectively hierarchical, so assigning multiple default roles to a user doesn't achieve much.

That said, I could imagine a situation where core provides a hidden UI for assigning multiple roles to a user, which can be enabled via a filter. So when a plugin implements custom roles, it can also enable the multiple role UI in core via a filter.

Before we get to that point, the UI needs to be fleshed out. What does it actually need to do? Is it enough just to replace the Role dropdown with some checkboxes? What else needs to be considered?

[galbaras]

Adding multiple roles is just an option. The main aim is to limit operational administrators from causing mayhem on their own sites just because they think they can.

Customizer can be a superset of Administrator and Developer can be a superset of Customizer, if the powers that be deem it appropriate. I'm just saying that when an agency builds a site and hands over to a client, it will be very useful to limit the client's ability to change the site's code, styles and theme settings.

Perhaps Administrator can remain, and a role of Manager can be added above Editor, which can manage users (up to Manager role), view logs and manage some kinds of information, but nothing related to presentation.

It's not easy, either way, because there are plugins that affect content and plugins that handle security, so its hard to create generic rules for plugin management and plugin configuration.

[lukecavanagh]

@galbaras

So are you thinking of more of a user role editor in core than just a UI for being able to select additional user roles with the related permissions.

This seems more like user permissions on user roles.

[galbaras]

@lukecavanagh I'm thinking of a separation of capabilities between development, customization and operation. I trust the WP community to find the best way to implement this, but the ultimate aim is to allow agencies to lock down certain aspects of the site from users while the site is under agency support.

This is a real life situation that creates many problems for both parties and the tighter the solution, the greater the benefit.

Personally, I think that a flexible role assignment will provide the most functionality, including things that the WP core developers may not anticipate, but as long as capabilities are separated roughly into development, customization and operation, a hierarchy is find by me.

Just consider the possibility that some companies may want their IT department to change the logo in the theme settings, but not to edit the home page, in which case customizing is not a superset of editing.

[karmatosed]

To me, this feels like plugin territory over having to be something in core. We discussed this in todays design triage, s a result I am removing the feedback tag.

[karmatosed]

After further discussion, recommending for closing. You can find plugins that will do this here: ​https://wpdean.com/wordpress-plugins-to-extend-user-roles-capabilities/

[galbaras]

Is it THAT difficult to convert the role dropdown into a multi-selection list box? The current role assignment may suit a blog, but it doesn't suit a CMS, which WordPress now is.

Also, why hide something WordPress supports in the first place and require a plugin to re-enable it?

[johnbillion]

Seeing as the default roles in WordPress are effectively hierarchical and it doesn't make sense for a user to have more than one of the default roles, I think this is best left up to a plugin to implement.

Plugins such as ​Members, ​User Role Editor, and ​bbPress all provide interfaces for this.

[galbaras]

Yes, but there are many plugins that create additional roles on a parallel axis, and allowing this, besides being super easy to do, is part of the "pluggable" environment.

I'm at WordCamp Brisbane and have spoken to a few people and they seem to agree this is both easy and useful. I seriously don't see the downside of it.