Problem/Motivation

When using revisionable entities, 2 issues can appear with moderation states as we have the concept of default / non default revision:

  • The newly created revision is based on the default one, which skips any non default revision
  • The difference (add / delete) is based on the default revision, not the latest one

Steps to reproduce

Setup
  • Drupal core latest stable (9.4.x at the time of writing)
  • Use the default Article content type
  • Use the default Tags vocabulary
  • Add a field_content on the Tags vocabulary
  • Configure CER to use tags / content fields (see below)
  • Enable content moderation with the default editorial workflow, apply it to the Article content type
  • Create a "Tag 1" taxonomy term in the Tags vocabulary
  • Ideally test on a multilingual setup so we cover this as well (make Article translatable, Tags as well)
  • Cases described above are reproducible with the source language only

CER tags - article

Test 1: edit the node only
  • Create a published "Article 1" with "Tag 1" set and "Revision 1" in the body
  • CER adds Article 1 reference to Tag 1 ✅
  • Delete in a Draft of Article 1 the reference to Tag 1
  • CER already deletes the reference to Article 1 on Tag 1 ⚠️ we could potentially wait for a default revision of the Article here?
  • A new published / default revision of Article 1 with the deletion of Tag 1 is created, with the same timestamp as the previous published and resets the body field as well ❌ not expected, as there is potential content loss from the draft if a content editor starts to edit, it might be hard to recover by reverting a revision
Test 2: add the node, keep it published, edit the term only
  • Create a published "Article 2", with "Tag 1" set
  • Delete Article 2 reference on Tag 1
  • A new Published revision of Article 2 is created with the deletion of Tag 1 ✅
Test 3: add the node, create then a draft and keep the reference to the term, edit the term only
  • Create a published "Article 3", with "Tag 1" set
  • Save a new draft of Article 3, still with Tag 1 set
  • Delete in Tag 1 the reference to Article 3
  • A new published / default revision of Article 1 with the deletion of Tag 1 is created ❌ same case as the first test

Proposed resolution

A simple one: when using revisionable entities, no need to specifically check with workflows/content moderation, always use the latest revision if the entity implements RevisionableInterface.

Possible follow-up (configurable?): if one of the entity is not in the default revision state, defer CER sync until it reaches the default state. This could be useful to not alter corresponding entities when not expected. Example: A draft product removes or adds references to a product category term or another product that is published, we might want to defer on these corresponding entities only when the draft product gets published.

Remaining tasks

  • Provide a patch
  • Test on non translatable content
  • Test on translatable content with entity reference not translatable
  • Test on translatable content with entity reference translatable

User interface changes

n/a

API changes

n/a

Data model changes

n/a

CommentFileSizeAuthor
cer-tags-article.png155.84 KBcolorfield

Issue fork cer-3326089

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

colorfield created an issue. See original summary.

colorfield’s picture

Pushed a first take, tested on non multilingual setup. Needs more testing / multilingual setup might use getLatestTranslationAffectedRevisionId().

colorfield’s picture

Status: Active » Needs work
anybody’s picture

Version: 8.x-4.x-dev » 5.x-dev
tbcs’s picture

This patch works for me. I'm interested in what remaining work should be done.

smustgrave’s picture

Category: Task » Bug report
Priority: Normal » Critical

Opened the MR but also think this is a critical bug. We had it reported that pages in draft were auto publishing whenever a reference field was updated. And we tracked it down to this module.

smustgrave’s picture

FYI when I said open I mean whatever was on the branch I didn't add anything.

smustgrave’s picture

Title: Integration with content moderation » Module is auto publishing pages configured with a cer relationship
smustgrave’s picture

Didn’t mean to hijack the issue if im off change the title back. Currently trying to see if this is a security vulnerability.

But steps I was able to replicate
1. Publish a page
2. Save a new draft
3. Edit draft again editing a ref field configured with cer.
4. Save as another draft
5 see that page auto published

smustgrave’s picture

Status: Needs work » Needs review
anybody’s picture

Thanks for the important fix @smustgrave - code LGTM.

I guess it would make sense to add tests for this to ensure it works as expected now and in the future?

smustgrave’s picture

Can try and find time. Actually see this module has almost 0 test coverage :(

anybody’s picture

Status: Needs review » Reviewed & tested by the community

1%! :D

I'll set this RTBC and maybe we just create a follow-up?

PS: Just saw I'm maintainer, didn't have that in mind any more. I'll merge this then and create a follow-up for tests.

anybody’s picture

Status: Reviewed & tested by the community » Fixed
Related issues: +#3572483: Write tests

I created a "Write tests" issue: #3572483: Write tests

Thank you very much @smustgrave!!

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.

Status: Fixed » Closed (fixed)

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