When creating a new revision, the new revision is always made the default revision if the previous default revision is unpublished

Created on 21 June 2023, about 1 year ago
Updated 15 November 2023, 7 months ago

Problem/Motivation

New revisions that follow a previous unpublished default revision are always made the new default revision regardless of any workflow settings to the contrary. This is in contrast to the behavior experienced for revisions following a published default revision.

As a result, "forward drafts" can not be "set as current revision" prior to a state change (to a state that makes it "Published" for example). This behavior is possible when "forward drafts" are created while the current default revision is published.

I believe that this can be traced back to an issue before the workbench_moderation module was copied to core ( Latest revision should become default revision when entity has never been published β†’ ). It appears that the original intent was to make each new revision of an entity that was not yet published the new default revision as it is created.

This is supported in the issue description:

Given I create a moderatable entity in a non-published state (e.g., draft)
And I transition the entity to another non-published state (e.g., review)
Then the latest revision should become the default revision

However, if an entity has been previously published, and then unpublished, it doesn't seem to make sense to continue to make each subsequent revision the default revision any longer.

Steps to reproduce

  1. Create a revisionable entity with the default workflow assigned.
  2. Create a new revision with a moderation state that is "published."
  3. Create a new revision with a moderation state that is "unpublished."
  4. Create a new revision with a moderation state that does not have the "Default Revision" checkbox checked.
  5. Observe that the new revision is the default revision.

Proposed resolution

Adjust the technique used to determine if an entity revision should be set to "default revision".
See Drupal\content_moderation\EntityOperations::entityPresave()

πŸ› Bug report
Status

Needs work

Version

11.0 πŸ”₯

Component
Content moderationΒ  β†’

Last updated about 13 hours ago

  • Maintained by
  • πŸ‡¦πŸ‡ΊAustralia @Sam152
Created by

πŸ‡ΊπŸ‡ΈUnited States Jeff Cardwell

Live updates comments and jobs are added and updated live.
  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

Sign in to follow issues

Comments & Activities

  • Issue created by @Jeff Cardwell
  • πŸ‡ΈπŸ‡ͺSweden erik.erskine

    erik.erskine β†’ made their first commit to this issue’s fork.

  • last update 11 months ago
    29,354 pass, 20 fail
  • @erikerskine opened merge request.
  • Status changed to Needs review 11 months ago
  • πŸ‡ΈπŸ‡ͺSweden erik.erskine

    We have a use case to put a node into an archived state, allow subsequent drafts to be made, and compare those revisions with the archived revision.

    The current behaviour - in `EntityOperations.php` - will always update the default revision if the previous revision was unpublished, regardless of what the moderation state's "default revision" property is set to:

    $update_default_revision = $entity->isNew()
      || $current_state->isDefaultRevisionState()
      || !$this->moderationInfo->isDefaultRevisionPublished($entity);
    

    The third condition here is very broad. It covers the "only ever been draft" use case, but not the "archived, then draft" use case.

    Here is a proposed change that will update default revision in the following circumstances:

    • the entity is new (same as now)
    • the moderation state dictates the revision should become the default (same as now)
    • the previous revision was the default AND the state does not change

    Patch/MR done to get things started.

  • Status changed to Needs work 11 months ago
  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Thank you for reporting.

    This will require a test case to show the issue.

    Also the MR should be updated for 11.x as that's the current development branch. Fixes can be backported depending when they land.

    Thanks.

  • πŸ‡³πŸ‡ΏNew Zealand John Pitcairn

    This was biting me today as part of a broader attempt to make moderation behave the way a client expects.

    My current solution is to swap out NodeModerationHandler and override ::onPresave() to avoid changing the default revision unless we are publishing. The handler is marked @internal however so that's not ideal.

  • πŸ‡³πŸ‡ΏNew Zealand John Pitcairn

    My client's expected workflow looks like this:

    states:
        initial:
          label: Unpublished draft
          published: false
          default_revision: true
        published:
          label: Published
          published: true
          default_revision: true
        draft:
          label: Pending draft
          published: false
          default_revision: false
        unpublished:
          label: Unpublished
          published: false
          default_revision: true
Production build 0.69.0 2024