Add permissions for optional modules to content editor role as they become enabled

Per #3059984-63: Add new “Content Editor” role to Standard Profile, tagging Security improvements.

Re-posting my comment #3221258-4: Fix content editor role to only have permissions that exist here as it's relevant here as well:

My first thought would be, how many of the permissions in question relate to modules that will be installed in the standard profile in the future (e.g. media, content moderation, etc)?

There were extensive discussions around the content editor role during UX Calls, and if I remember correctly, we did discuss the idea of adding permissions to the role as those modules become included in the standard profile.

I think the easy approach is just to remove the effected permissions, and then create separate issues for the relevant modules that will eventually be installed in the standard profile to update the content editor role as part of the inclusion process.

The thing that we discussed during the UX Calls is that this role (and the Content Manager role) is really just meant to be a sensible starting point, not really a be-all-end-all of that type of role. We noted that we wouldn't want to then later update existing sites because they may have customised this role beyond what our default is meant to represent, and maybe deleted it all together. With that in mind I think using hooks to add the permissions on install of specific modules is probably a bit overkill for what the intention of these roles are supposed to be, and possibly could create more problems for existing sites.

Thanks,
-Aaron

This issue wont be unique to standard
So if the quick fix is remove those permissions and then focus on a real API for optional permissions, +1 to that
I've made my thoughts on standard profile known, so not repeating them here

Some of the modules make sense to have in standard, e.g. media. That topic has been held up on some UX discussions and a migration, which I think is not even desirable, not automated anyway. standard should never do anything to existing sites, and solely exist as a starting point for new sites.

But other modules will definitely not every be added to standard. Everything around translation for example, that by design only makes sense as soon as you have multiple languages.

So yes, a generic concept of optional permissions is interesting, but that's a layer of optional config that we haven't explored yet at all..

I'm starring to see an interesting feature proposal here for "suggested permissions", I think "optional" is probably the wrong word for this. So when you install a module it can suggest sets of permissions that you might want to give to specific roles.

That's a slightly different use case though, because we're still talking about standard.module suggesting to do something when you install media. The module module can't do that itself, because it must not have any knowledge of the content editor role, only standard profile knows that. Other install profiles/sites might have similar roles, but they will have different names.

That's a slightly different use case though, because we're still talking about standard.module suggesting to do something when you install media. The module module can't do that itself, because it must not have any knowledge of the content editor role, only standard profile knows that. Other install profiles/sites might have similar roles, but they will have different names.

Yeah that's fair, when I wrote that I had in mind a discussion that came up at a UX Call when we were looking at #2919636: Design a better model for managing permissions, which then spawned the issue #3216341: Provide a module-specific permissions form.

As I see this will be a major issue for distributions.

To solve the missing permissions I would expect something like this:

profiles/standard/config/optional/user.role_permissions.content_editor.media.yml

dependencies:
  module:
    - media
id: content_editor.media
permissions:
  - 'access media overview'
  - 'revert all media revisions'
  - 'view all media revisions'

profiles/standard/config/optional/user.role_permissions.content_editor.media.image.yml

dependencies:
  config:
    - media.type.image
  module:
    - media
id: content_editor.media.image
permissions:
  - 'create image media'
  - 'delete own image media'
  - 'delete image media revisions'
  - 'edit own image media'

In ideal case permissions should be even removed from the user.role.<role_name> config.

It's fairly easy to work around this, you don't need a fancy API. Just implement hook_modules_installed(), check for module X, if being installed, grant the desired permissions to the role you want.

Yes, sure, but I prefer to have config in yaml files, not in PHP code. To easily track config changes.

Now that The Recipe Initiative APIs have been added to core as experimental, we have a new option for solving this problem. We can use a recipe to install a module and add permissions from that module to existing roles, such as the content_editor role.

MR 9651 provides a proof of concept: it adds recipe.yml to the content_moderation module. The recipe does the following steps:

1. Install the content_moderation module.
2. Install related optional configuration (for the editorial workflow) from the standard profile.
3. Grant permissions, which depend on the module and the configuration, to the content_editor role.

Now, I have the option of installing the module or applying the recipe. Using Drush, the two options are

• drush en content_moderation
• drush recipe core/modules/content_moderation

Of course, any other recipe that wants to install the module can apply the recipe instead.

I do not have any other examples in mind, but I suspect that there are many modules that can benefit from the same approach.

Comment #2 added the "Security improvements" issue tag. I think the security improvement was already done by the related issue #3221258: Fix content editor role to only have permissions that exist, so I am removing the tag from this issue.

You could simplify the recipe a bit by using standard's editorial_workflow also so you also get the optional views.view.moderated_content config which you aren't importing currently.

name: 'Content Moderation'
description: 'Adds permissions to standard user roles for the Content Moderation module.'
type: 'Users'
recipes:
  - core/recipes/editorial_workflow
config:
  actions:
    user.role.content_editor:
      grantPermissions:
        - 'view any unpublished content'
        - 'view latest version'
        - 'use editorial transition archive'
        - 'use editorial transition archived_draft'
        - 'use editorial transition archived_published'
        - 'use editorial transition create_new_draft'
        - 'use editorial transition publish'

Thanks for that suggestion. I did not realize that core/recipes/ had any recipes beyond what the standard profile uses.

Another option is to add these permissions in the editorial_workflow recipe or in a new recipe under core/recipes/.

Either way, we should probably add a dependency on the content_editor_role recipe.

Can the issue summary be updated as well please.

I am updating the Proposed resolution in the issue summary (and making minor edits to the rest).

I updated the MR to add the permissions in the existing editorial_workflows recipe.

In Comment #21, I wrote,

I did not realize that core/recipes/ had any recipes beyond what the standard profile uses.

I see now that this recipe was created as a place to put the optional configuration workflows.workflow.editorial from the standard profile. Since the permissions I am adding depend on the workflows transitions defined in that configuration entity, I think it is a good idea to put the permissions and the config in the same recipe.

I would like further review of this issue, but I am leaving the status at NW because there are other permissions from other modules that I want to add.

Looking at #3221258: Fix content editor role to only have permissions that exist, these are the permissions that were removed, grouped by module:

Core modules

1. content_moderation
   • use editorial transition archive
   • use editorial transition archived_draft
   • use editorial transition archived_published
   • use editorial transition create_new_draft
   • use editorial transition publish
   • view any unpublished content
   • view latest version
2. content_translation
   • create content translations
   • delete content translations
   • update content translations
3. media
   • access media overview
   • create media
   • delete media
   • update media
   • view all media revisions
   • view own unpublished media

Contrib modules that used to be part of core

1. aggregator
   • access news feeds
2. book
   • access printer-friendly version
   • add content to books
   • create new books
3. node module, if the book content type is defined (optional config in the book module)
   • delete own book content
   • edit own book content
   • delete book revisions
   • create book content
4. statistics
   • view post access counter

MR 9651 already handles the permissions from the content_moderation module. It should also handle permissions from the content_translation and media modules. We might need new recipes for these: none of the core recipes enable either of these modules directly. The *_media_type recipes enable media indirectly (by enabling the media_library module). Perhaps one of the core recipes enables content_translation indirectly, but I do not think so.

What about the aggregator, book, and statistics modules? (These modules were in Drupal core when the content_editor role was created, but have since been removed.) One option is to create separate projects on d.o with recipes for each. If we consider letting modules define their own recipes, as I suggested in Comment #18, then we could add recipes to those contrib modules and add the permissions in those recipes.

Modules can’t provide recipes. Recipes need to be their own packages and kept in a single folder suggested to be above web root.
Core recipes location is the only exception.

This is so the recipe runner knows where to look for dependent recipes.

Modules also can contain recipes as there would be conflicts with the config folder as recipes and modules have different needs and structures.

We discussed this issue briefly at #3477161: Drupal Usability Meeting 2024-10-04. That issue will have a link to a recording of the meeting.

@rkoller pointed out that I should consider the recipes in https://git.drupalcode.org/project/drupal_cms as well as the core recipes. In particular, the drupal_cms_multilingual recipe already enables the content_translation module and adds permissions to the content_editor role. Probably nothing more has to be done for that module. I have not yet looked for recipes that enable the media module.

For the record, the attendees at the usability meeting were AaronMcHale, avani.bhut, benjifisher, rkoller, shaal, simohell, and zetagraph.