Add Content Editor, Content Manager roles to the Standard profile

And/or add a "site builder" role

Confusion over which permissions are best associated with the day-to-day activities of authors, editors, admin, and site builder is a perennial problem. It is the basic context which is needed for non-technical folks to start making sense of what they need in role building.

Some narrowly scoped roles could help jumpstart such orientations, and serve as a useful basic persona for implementation teams and contributors.

But, subjective. Bikesheds to choose initial permissions, more to consider adding new permissions, random bug reports by people who disagree with out-of-box definition.

All true, don't think that should stop us from trying to figure something out :)

Lets see if we can clarify the what, why, who and how a bit. I added the "idea template" to the issue summary. Short answers to the 4 questions will help us compare and weigh ideas for their relative impact. Thank you!

Updating summary content answering @yoroy's questions to try to move this issue forward. We are proposing an initial plan because it has been defined as one of the strategic steps for the Admin UI initiative in #3024584: Directional Feedback for the Next-Gen Admin UI. Thoughts?

Fixing summary html... always get it bad.

I´d like to help out on this issue to define requirements. I can also help with the survey and finding testers.

As @Grayside mentioned above, this confusion is a perennial problem. We are working out ways to add more default roles to our distribution, but it would be better if there was an initial setup that came in Drupal core. It doesn´t make sense that for every installation we have to create the same set of permissions for each project.

For example, we came up with a preliminary set of backend permissions (still draft):

For some projects, a content manager would not do sitebuilding and user management, so that might be removed from the default set of permissions.

(Don't mind me. Just fixing a couple of the external links in the issue summary, which were broken due to the inadvertent use of typographers' quotes.)

+1 on adding an editor role. I think this is something that people come to expect (probably because WP does it).
-1 on adding a 'site builder' role. I don't think the 80% would use that. I'd expect that 80% of the site building goes from the admin role. I'm not sure what the benefit would be.

Here's a patch that adds an editor role to the Standard profile.

The introduction of config management gave us a clear line between what editors should be doing with 'content' on the live site and what site builders should be deploying to the live site as 'config.' Now we need to bring that clarity into the user interface. Ultimately all the site permissions need to be divided into 'config' or 'content' permissions (splitting up any that are currently both) and core modules need to treat the two use cases differently (for example, toolbar module should have separate admin and editor toolbars).

Lots of follow up tasks needed here, but I think these starting permissions are a good start. Essentially I gave editors permission to do anything that does not affect 'config.'

I've been trying to tackle this for years with Tasty Backend. Originally just a talk, there's now a module that optimises Drupal for day to day content administrators (editors).

https://www.drupal.org/project/tasty_backend

My approach has been to create two roles, Content Admin, and User Admin. Content Admins are responsible for day to day administration of content only, and cannot manage other users at all. The User Admin role has permissions to add/edit/delete other users only. The responsibility for user administration is much greater due to security concerns. Allowing users to edit other users, without a bit of help from contrib, also allows users to escalate their own privileges on the site by assigning themselves other roles, take over the user 1 account, etc. So two roles for this situation has always made sense to me.

The most important thing I've probably noticed in creating TB, is where core falls short in permissions. This is where TB relies on contrib. For content, TB requires the following modules:

• Menu Admin Per Menu
• Override Node Options
• View Unpublished

Menu Admin Per Menu is necessary since not all menus are for day to day content and I don't want to show those users anything that they shouldn't ever touch. The "Administration" menu is a good example of this. That's for admin links (in a menu that TB users don't have access to), not front facing content links, so content admins shouldn't be able to touch it, or even know it exists.

Override Node Options is useful for simplification of node forms, where options like sticky and promoted don't make sense. Part of the TB philosophy is simplification, so while probably not useful for a role in core, I do still wonder if some core features might not be needed for an editor role.

View Unpublished is vital, since a Content Admin needs to edit all unpublished content they're tasked to manage, and the core permission to view their own unpublished content falls short. Editors will need to be able to view and see other editors unpublished content, and view unpublished allows fine grained control over that.

For User Admins, TB currently relies on Role Delegation to make sure that users can't just add any role they want. Once again, if we allow a role to manage other users out of the box, they'll be able to just add the administrator role to whoever they want.

TB includes other features such as a separate admin menu, custom admin screens per content type, and other changes to keep site building and development tasks firmly away from users who shouldn't have access to any of that. So, probably a bit more than core needs for now, but maybe a good roadmap for further optimising what core can offer to make Drupal user friendly for day to day content administrators.

It would be great to align Umami with this change.

Umami currently has separate roles for Author and Editor

Originally Author was used for all content editing.

Editor was introduced when we wanted to showcase Content Moderation. Having a separate role let us demonstrate you could have Authors that could draft content but Editors were required to review and publish it. Editor in this sense was aligned with the role of an Editor in traditional publishing.

If Standard added an Editor role that was closer to our definition of an Author, we'd have to come up with a new name for our concept of an Editor to align with Standard.

@jeni_dc Re permission escalation you're mixing up two permissions: 'administer users' and 'administer permissions.' It is the latter that allows users to assign any role. Having additional permissions that allow users to assign other users to specific roles is necessary, but I see it more as a follow up to just getting an editor role in core.

@Eli-T the permissions are going to be a little different between standard and umami regardless because there are different modules enabled.

Lots of chat here about all different roles to add: a site builder role, an author role, a user management role. Can we agree that to start we should only be adding a single role: Editor.

Without allowing users to assign other roles with the 'administer permissions' permission, they really can't manage other users properly since they can't create other editors. So, that's why I mentioned Role Delegation. A user admin without being able to modify roles isn't really a user admin in my book, roles are central to Drupal users.

On top of that, even without the 'administer permissions' permission, any user with with the 'administer users' permission can edit the user 1 account, or any other account with the administrator role or other roles with more permissions. They can change that account's password, and then they've got full control of the site. So yes, there's still a security problem there. Other contrib like User Protect is needed to protect against that.

I'm not sure I would agree that one role should handle those different responsibilities, but it's Drupal, configure it how you like it, and one role is most likely easier for new users to grok. But let's keep in mind where core needs work to have that role be actually useful, even if just as an example. Otherwise we risk adding a role that provides a poor experience and insecure site.

Thanks all for the feedback, it's being really useful!

From the comments here and in Twitter it seems like at least 2 role levels might be needed, a basic "Content editor" and another one with more "Manager" related permissions. But we ideally should define a common situation and it looks like this "Manager" one might be the point where a lot of projects diverge.

So if we focus on this Content editor role, which would its common tasks? @Jody Lynn's patch is a great starting point. From there, I'd like to discuss a few of the permissions:

• 'access site reports': Do we really need to give this info to a content editor? What example situation could solve this?
• 'administer menu': Same here, do we really need this for a content editors? As @jeni_dc said, if we assume menus are content and give this permission to an editor it might be dangerous to give the chance to delete the admin menu. So, it might make sense to evaluate the integration of the Menu Admin per Menu contrib module or its functionality in core.
• 'delete any article/page content': This is the classic permission that could create some conflicts if site builders are not aware it's the default configuration.

Also, what do you think about adding a new menu for this role in a future iteration?

From experience on sites I have worked on, I agree with @ckrina that the administer menu and delete settings should not be given to the editor role. It is better to have a base set and be additive per what the site requires.

I think there are a lot of great, advanced use case ideas here especially in the area of permissions, site building, menus,... I would suggest to move those to a separate issue and focus this one on a content editor role.

We always build two roles: editor and manager.

Editor can manage any content (nodes, media, taxonomy terms, menus). Manager can manage any user and assign roles editor and manager (but administrator if exists).

In order to achieve a great user experience we remove all UI functionality which is not needed for editor and manager. We achieve that with contrib modules and some custom modules (basically preprocessing forms and entities to remove stuff).

It would be great to have something like this in core.

Hi everyone,

In the Admin UI Modernization Initiative, we created this quick survey to get feedback on the Content Editor role and possible permissions.

Would you take a moment to complete it, and also pass it around to your colleagues? Your input will help define this feature.

https://goo.gl/forms/th8XqKHfe1Pq1jJn2

Just wanted to mention that the GovCMS distro (go-to Drupal distro and SaaS offering for Australian gov agencies) ships with "Content Editor" and "Content Approver" OOTB.

We have the results in from the survey we distributed earlier to get some insight on adding the Content Editor role into core. You can read the report here.

To provide a quick summary: Of 166 responses at the time of analysis, 84% strongly agreed with adding a Content Editor role. The two top names favored by a large margin are Content Editor at 61% and Editor at 43% (multiple options could be selected).

The minimum set of permissions we recommend are:

• Create and edit new content — articles and pages
• Use the basic HTML text format
• View unpublished content
• Create and edit terms (tags and categories)
• Access the administration theme

We also asked about adding a Content Manager type of role, but based on the range of results for and against, we would not recommend to add it by default.

Recording from the UX meeting where this topic was discussed: http://youtu.be/uyilEZAZGNI

I think this is a great idea... as long as it is only "when Drupal is installed with the standard profile".

I maintain a Drupal distribution that does not use "nodes" at all (farmOS - for private farm record keeping), and provides it's own roles like "Farm Manager" and "Farm Worker". "Editor" doesn't make sense in this context because we are not using Drupal for website content management in the traditional sense. And in D8, we probably won't enable the node module at all. So many of the permissions of a "content editor" wouldn't apply.

Just want to make sure the non-traditional distribution maintainer voice is heard in all this! I'm sure you've already heard similar feedback. Great idea for the standard profile! +1 :-)

Of 166 responses at the time of analysis, 84% strongly agreed with adding a Content Editor role.

We have an agreement. :-)

The two top names favored by a large margin are Content Editor at 61% and Editor at 43%.

We need a final call here, but it seems like "Content Editor" is the favourable option. It could be useful for the ones only having this role and for the ones having a "content manager" or alternative roles. So I'd go for "Content Editor". Anyway, I don't think this is a blocking issue since it can still be defined on the on the working issue itself.

• Create and edit new content — articles and pages
• Use the basic HTML text format
• View unpublished content
• Create and edit terms (tags and categories)
• Access the administration theme

And a proposal for the MVP set of permissions, still to be defined.

So I guess next steps/plan could be:

1. Sign-off from the Product Managers. Someone else?
2. Create a plan width:
   • Define a final name
   • Decide on the best implementation+commit
   • Define final set of permissions+commit

@m.stenta yes, we're only planning this for the Standard profile and _maybe_ Out of the Box, still to be discussed with them.

Yes, it would be great to showcase this new role as part of the Out of the box installation profile.
After this role will be available in Drupal core, we'll change Out of the box installation to use that role.

This was discussed during the UX meeting on 2019-04-16 (https://www.youtube.com/watch?v=uyilEZAZGNI), and @webchick was there. Her feedback was:
- We already have enough research here to support the need of this new editor role, so we can move forward.
- Adding this new role won't affect current installations, so it's safe on terms of backwards compatibility.

She also suggested to create a meta issue to discuss what else we could do with the editor role in core. So @antonellasev has created this 2 issues:

• #3059984: Add new “Content Editor” role to Standard Profile
• #3059986: [META] New features for the new “Content Editor” role in Standard Profile

There was some enthusiastic discussion about this (and related) issues toward the end of the latest UX meeting at https://youtu.be/PpyHgnstVUE

TL;DL: Not having this role, at a system-level in Drupal, is really holding Drupal back from being able to do things like provide per-role dashboards, menus, etc. catered to their respective audiences.

Good news! There is already an issue and a patch for this waiting for:
- Decide on which permissions we should add (let's just try with an MVP?)
- Product Manager review

Feel free to jump in there and give opinion, and we can try to review that on next UX meeting https://www.drupal.org/project/drupal/issues/3059984

To be sure #3059984: Add new “Content Editor” role to Standard Profile doesn't get blocked after getting Product Manager approval I've created #3201550: Add new “Content Manager” role to Standard Profile to discuss which permissions should be more Content Manager related.

#3059984: Add new “Content Editor” role to Standard Profile has been committed. Should this be closed as a duplicate?

Maybe Fixed instead of Duplicated? The initial proposal has made it to core and we already have the follow-up for the Content Manager one. ( #3201550: Add new “Content Manager” role to Standard Profile )
Also, hooray! :D

It seems that no one is quite sure how to update this issue.

If "fools rush in where angels fear to tread", then I am willing to play the part of the fool.

I am marking these two issues as children of the current issue and removing them from the list of related issues, since that seems redundant:

• #3059984: Add new “Content Editor” role to Standard Profile
• #3201550: Add new “Content Manager” role to Standard Profile

I am also updating the issue title to mention both roles.

Once both of those issues are fixed, I think we can mark this issue as fixed.

I am adding #3196014: Revisit the modules enabled by the Standard profile as a related issue.