This issue is a follow up on the Content initiative BOF discussion.

Problem/Motivation

Content moderation needs to expose permissions for editing an entity depending on it's moderation state.

Proposed resolution

Add a permission for every (entity type, moderation state) pair.

Remaining tasks

Make sure solution works after #2801031: Provide a generic entity access handler and permissions gets commited to core.

Comments

blazey created an issue. See original summary.

blazey’s picture

Issue summary: View changes
blazey’s picture

Attaching patch with phase one - permission generation. It'd be great to validate the approach before going any further. Right now permissions are added for each entity type. Is bundle level control needed?

Next step is to implement the actual access checking. Should we wait until #2801031: Provide a generic entity access handler and permissions is be commited to core before doing this?

timmillwood’s picture

Status: Active » Needs review
Issue tags: +Needs tests
  1. +++ b/core/modules/content_moderation/src/ModerationInformation.php
    @@ -52,6 +50,15 @@ public function canModerateEntitiesOfEntityType(EntityTypeInterface $entity_type
    +  public function getModeratableEntityTypes() {
    

    We shouldn't use the word "moderatable", it's not a real word. Although getEntityTypesThatCanBeModerated() is a little long.

  2. +++ b/core/modules/content_moderation/src/Permissions.php
    @@ -40,4 +69,32 @@ public function transitionPermissions() {
    +          'title' => $this->t('Edit %state_label %entity_type', $replacements),
    

    Just wanted to point out that each bundle within an entity type can have different moderation states. I'm not sure if we need to worry about that, but just in case anyone has any interesting ideas.

This initial patch just adds an edit permission, do we need create, read, delete permissions too?
Also do we need an edit any state? I guess core ships with edit permission, should the core permission be edit any, then these permissions be specific?

timmillwood’s picture

We already have a patch #2800117: Add getModeratedEntityTypes to Content Moderation ModerationInformationInterface being worked on for getting entity types that can be moderated. Might be worth pooling efforts and getting that in, then using it for this.

blazey’s picture

Status: Needs review » Postponed
Issue tags: -Needs tests
StatusFileSize
new7.43 KB
  1. Changed the name of the method for now. It can be removed once #2800117: Add getModeratedEntityTypes to Content Moderation ModerationInformationInterface is ready.
  2. Looks like this part also needs to wait for above-mentioned issue.
  3. Added two test methods, one for permission generation and the other for entity access (not yet implemented, waiting for #2801031: Provide a generic entity access handler and permissions).

I don't see a way to select moderation state during node creation, so all entities start their lifecycle in default state, right? Separate 'create' permission may seem redundant because of that. Read and delete make perfect sense, though.

timmillwood’s picture

After speaking to AlexPott yesterday there was concern that this would add too many permissions. I think we need to get sign off from core maintainers before continuing with this.

timmillwood’s picture

Needs rerolling for 8.3.x, also still think we need sign off from committers.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

anish.a’s picture

Issue tags: -Needs reroll
StatusFileSize
new5.27 KB

Rerolled to 8.4.x

anish.a’s picture

Status: Postponed » Needs review

Status: Needs review » Needs work

The last submitted patch, 10: moderation_state_edit_permission-2808309-10.patch, failed testing.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

tom friedhof’s picture

Is there a way to manage access to an entity when it is in a specific state? Looks like this issue has started to work on a solution. The patch above only adds the permissions to the Permissions page. I think a better solution would be to put the roles on the edit_state_form:/admin/config/workflow/workflows/manage/{workflow}/state/{workflow_state}

Curious if this issue is being solved in a different thread.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Needs work » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.