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.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | moderation_state_edit_permission-2808309-10.patch | 5.27 KB | anish.a |
Comments
Comment #2
blazey commentedComment #3
blazey commentedAttaching 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?
Comment #4
timmillwoodWe shouldn't use the word "moderatable", it's not a real word. Although getEntityTypesThatCanBeModerated() is a little long.
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?
Comment #5
timmillwoodWe 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.
Comment #6
blazey commentedI 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.
Comment #7
timmillwoodAfter 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.
Comment #8
timmillwoodNeeds rerolling for 8.3.x, also still think we need sign off from committers.
Comment #10
anish.a commentedRerolled to 8.4.x
Comment #11
anish.a commentedComment #14
tom friedhof commentedIs 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.
Comment #26
smustgrave commentedThank 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!