Content moderation check does not take into account entity IDs being used by two content entities

Created on 29 April 2020, over 4 years ago
Updated 16 August 2024, 2 months ago

Apologies if this belongs in the content moderation component. I figured it's linked more to the experimental workspaces functionality.

I'm currently working on a fix and will attach a patch.

Problem/Motivation

The check in content_moderation_workspace_access() in the content_moderation module where tracked revisions are queried for their moderation state does not take into account the entity type. This causes an issue where an id/vid is shared by more than one entity type.

As an example - here a path alias has a revision ID of 9146.

*************************** 1. row ***************************
                workspace: xyz
    target_entity_type_id: path_alias
         target_entity_id: 9141
target_entity_revision_id: 9146

We also have a node with vid 9146 which is not tacked in a workspace:

*************************** 1. row ***************************
               nid: 1656
               vid: 9146
          langcode: en
      revision_uid: 86
revision_timestamp: 1579865672
      revision_log: NULL
  revision_default: 1
         workspace: NULL

The path alias revision ID makes it's way into $tracked_revision_ids in

  // Check if any revisions that are about to be published are in a non-default
  // revision moderation state.
  $query = $entity_type_manager->getStorage('content_moderation_state')->getQuery()
    ->allRevisions()
    ->accessCheck(FALSE);
  $query->condition('content_entity_revision_id', $tracked_revision_ids, 'IN');

which is not aware of entity type. This returns this row and prevents the workspace from publishing:

*************************** 1. row ***************************
                           id: 2096
                  revision_id: 10441
                     langcode: en
                          uid: 86
                     workflow: fca_workflow
             moderation_state: draft
       content_entity_type_id: node
            content_entity_id: 1656
   content_entity_revision_id: 9146
             default_langcode: 1
revision_translation_affected: 1

Steps to recreate

  1. Clean Drupal install
  2. Enable workspaces & content_moderation
  3. Enable workflow on node bundle basic page via /admin/config/workflow/workflows/manage/editorial
  4. In the live workspace create a basic page, save it, edit the it and save it again such that there will be two revisions vid in content_moderation_state_field_data = 2, (do not publish the node!)
  5. Switch to the Stage workspace
  6. Create a URL alias in Stage workspace via /admin/config/search/path/add
  7. Attempt to publish Stage workspace -> SQL error due to no entities in workspace apply to workflow (fixed in patch)
  8. Still in the Stage workspace, change the workflow state of the basic page created above to Published to address the error from the previous step
  9. Now attempt to publish the workspace again -> this fails as node the checked revision in \Drupal\content_moderation\EventSubscriber\WorkspaceSubscriber::onWorkspacePrePublish is the one of the url alias and not as expected the one of the node

Proposed resolution

Tweak content_moderation_workspace_access() to utilise content_entity_type_id.

Remaining tasks

  1. Create patch
  2. Test
  3. Review
🐛 Bug report
Status

Closed: duplicate

Version

11.0 🔥

Component
Content moderation 

Last updated about 14 hours ago

Created by

🇬🇧United Kingdom alexj12

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇺🇸United States smustgrave

    Enabled content moderation and workspace modules
    Added Article node to workflow
    In live workspace created a node with multiple revisions - left all in draft
    Switched to stage workspace
    Added an alias to the node
    Tried to publish content but I get "The Stage workspace can not be published because it contains 1 item in an unpublished moderation state."

    There a missing step for testing?

  • Status changed to Needs review 11 months ago
  • The patch from #28 didn't apply on 10.1.x and porting it as it was didn't work either, thus here a patch that works and applies on 10.1.x. Also updated the steps to replicate in the IS.

  • last update 11 months ago
    Patch Failed to Apply
  • Issue was unassigned.
  • Status changed to Needs work 11 months ago
  • 🇺🇸United States smustgrave

    Can this be converted to an MR please. Changing to development branch.

  • First commit to issue fork.
  • Status changed to Needs review 11 months ago
  • 🇮🇳India ankithashetty Karnataka, India

    Raised an MR for the changes in #31, thanks!

  • Status changed to Needs work 11 months ago
  • 🇳🇱Netherlands ekes

    Looking at this for the first time, having encountered it on a site in development, and it seems that this can not only happen if there as explained in the OP:

    A non-workflow non-revisionable entity with a revision id that is the same as another different entity type revisionable entity (previous not default) revision id that is in a non-published state (the path_alias and node example)

    but also if there is:

    Any (including workflow revisionable) entity with a current default state revision id (published) that is the same as another different entity type revisionable entity (previous one not the current default) revision id that is in a non-published state.
    eg: A taxonomy term ID 1, Revision 1 Published; and Node 1, Revision 2 Published (but also a Revision 1 not published).

    The $tracked_revisions https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/conte... returned are going to be $tracked_revisions = [ 'taxonomy_term' => [1], 'node' => [2] ] which becomes $tracked_revision_ids = [1, 2] when queried in the table https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/conte... will return 1 because it is catching the tracked, but no longer relevant node revision.

    Looking at the base test class ContentModerationStateTest and WorkspacesContentModerationStateTest extend it, only one entity type is tested at a time for this. So it feels like it might be clearer to make a new test that reflects workspaces behaviour more, where several entities of different types are being published at the same time - obviously with some clashing revisions id's included.

  • Status changed to Closed: duplicate 2 months ago
  • 🇷🇴Romania amateescu

    Closing as a duplicate of 🐛 Content Moderation prevents workspace deployment Needs work , I've transferred the credit over there for people who worked on this issue.

Production build 0.71.5 2024