Problem/Motivation

This problem was surfaced in the Workspaces module, and it seems to be a regression from the behavior change introduced in #2839195: Add a method to access the original property . Quoting from that issue's change record:

Note the slight behavior change when saving non-default revisions. Previously, the original property was always the unchanged default revision, now it is the revision that had been loaded, so when saving a new non-default revision based on a previous non-default revision or updating it, changes can be correctly detected.

When publishing a workspace, we are re-saving the latest workspace-specific revision as the new default revision for each tracked entity. This mostly works at the moment because we're also manually setting the default revision on the original property.

However, this breaks for entities that follow the revision status of their "parent", but aren't themselves tracked by the workspace (e.g. revision references to a paragraph), because the workspace publisher can't set the original property on them.

Additionally, after that issue, we should be setting original to be the latest revision itself, not the default one.

Steps to reproduce

Reproducing the issue involves using Workspaces, Paragraphs, and ERR with the patch from #2984027: Incorrect manipulation of default revision flag. Manual steps would be quite involved and difficult to follow, but the test coverage added here shows the problem quite well.

Proposed resolution

Allow pending revisions to saved as the default one "in-place", without having to create a new revision.

Remaining tasks

Review.

User interface changes

Nope.

Introduced terminology

N/A

API changes

Nope.

Data model changes

Nope.

Release notes snippet

N/A

Issue fork drupal-3554269

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

amateescu created an issue. See original summary.

berdir’s picture

Status: Needs review » Reviewed & tested by the community

Lets make sure we open and link that follow-up, but the fix makes sense as discussed in the review thread and we can revisit in the follow-up.

  • catch committed b862bc7b on 11.2.x
    Issue #3554269 by amateescu, berdir: Impossible to save a pending...

  • catch committed c0d521a7 on 11.x
    Issue #3554269 by amateescu, berdir: Impossible to save a pending...

catch’s picture

Version: 11.x-dev » 11.2.x-dev
Status: Reviewed & tested by the community » Fixed

This looks good, given the need for an 11.2.x backport agreed with handling the optimisation in a follow-up, looks promising though.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

  • catch committed bbe7f03f on 11.3.x
    Issue #3554269 by amateescu, berdir: Impossible to save a pending...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.