Moderation state is the same for all node's translations in edit page

Hello! I'm advising a client on how to get independently-moderated translations working, and they've run into what seems to be a bug even with this patch (and https://www.drupal.org/project/drupal/issues/2430335 and https://www.drupal.org/project/drupal/issues/2983958) installed.

Steps to reproduce:

* First off, this is on Drupal 8.6.4.
* Apply the patch in this issue, as well as in the other two linked above.
* Create and publish a node in the site's default language (let's say "English").
* Create and publish a translation of that node in another language (let's say "Spanish").
* Create and publish a translation of that node in yet another language (let's say "French").
* Send the Spanish translation to the "draft" state. At this point the drafts list is correct —it should only include the Spanish translation.
* Send the French translation (the default) to the "draft" state. Drafts list is still correct —it shows both.
* Send the Spanish translation to the "needs review" state. In this situation, _sometimes_ the drafts list shows both (correctly), but occasionally it will only show Spanish, and French disappears.
* Send the English translation (the site's default language) to the "draft" state. At this point the site errors out, and the logs show "Drupal\Core\Entity\EntityStorageException: "The default translation flag cannot be changed (fr)."

It sort of seems like maybe each time a non-default translation is moved into a draft state, the node's default translation flag is changing with it?

@luisnicg nice catch and great instructions to reproduce. I can confirm the issue and also confirm your patch in #3 also fixes this.

Adding a test case for this, if these patches go fail/pass, this looks ready to me.

The problem in #6 is occurring for us with this patch installed. Is that a by-product of this patch or a completely separate issue?

@AMDandy can you remove the patch and re-test the issue to make sure we haven't introduced a regression with this issue?

We use paragraphs as well. We've found that it only triggers if a user actually tries to change the default language, though. At least I couldn't get it to trigger by following the steps above or by trying normal content editing/workflow steps.

Patch #7 still applies, has tests.

I have also encountered this issue when developing content_moderation support for the ETUF module (entity_translation_unified_form).

I have not yet tested this patch, but it looks like it will fix something that I had previously done and replace (code I wrote for) a workaround bypass of the Drupal api in an effort to fix a valid use case for the entity_translation_unified_form module.

In addition, I found that if a translation is added on the creation of a node entity that the moderation state is not added correctly for the translated version and that the only way to fix this through the current drupal api is to add a new revision after saving. a new core issue should be spun off for what I am describing.

With that said, patch #7 seems to be in the right direction and has tests.

I've found a problem when this patch is used...

I have defined a workflow with these states:

1. Draft
2. Needs Review
3. Published

We have two roles:

• author (Who creates content in draft and sets it to "needs review")
• admin (Who can transition from "needs review" to "published")

Now to the problem:
An author has created a node in English, and sets it to "needs review".
Now the author wants to add a german translation for this node. He goes to the Translate tab and clicks on the "Add" Button.
The form where he can edit the node and add the german texts is displayed.
Wen he clicks "Save" he gets the error message "Invalid state transition from Needs review to Needs review".

Logically that is correct, because the author role doesn't have the permission to edit nodes which are in the state "needs review".

But shouldn't new translations be created as "draft"?
Is it possible to force the new translation be created as "Draft"?

I didn't end up using this patch, instead I ended up using the api to acheive a moderation state sync

$revisionable_entity->setRevisionTranslationAffected(TRUE);

if you do not want this then try the opposite

$revisionable_entity->setRevisionTranslationAffected(FALSE);

I've found out that there is a problem with the function ModerationInformation::getOriginalState().
This function should return the initial state of the workflow for new translations.

I've added a patch that adds this functionality.

Please don't report and work on multiple problems in the same issue, it makes it hard for reviewers and committers to know what's what.

Please search the queue or use the "content moderation multilingual bug" to find the bug you've reported and work on two seperate patches.

Reuploading #7 which has a red/green patch already.

Fixing IS.

Thanks @Sam152!

One nitpick:

+++ b/core/modules/content_moderation/tests/src/Kernel/ModerationStateFieldItemListTest.php
@@ -401,4 +401,33 @@ public function testWithExistingUnmoderatedContent() {
+   * Test the field item list translation support with unmoderated content.

Tests that the field ...

This looks good to me, the only thing missing is to link to a related issue / follow up that covers #20

Thanks for the review @jungle, didn't realise that was a thing. Updated!

Thanks @larowlan, adding that as a related issue now.

I tried to do manual testing, failed to finish it, even I got myself confused, giving it up 🤦. So just a general RTBC +1 to the patch as the testing passed, and the test-only patch failed as expected.

Manually tested, the patch in #28 works as expected. See the attached Gif files. tried with English and Simplified Chinese, (my native language), "草稿" means Draft in English.

Tagging "Bug Smash Initiative"

Committed 685f3a0 and pushed to 9.1.x. Thanks!

c/p to 9.0.x

Leaving it RTBC, and moving to 8.9.x for possible backport

same patch applies cleanly to 8.9.x , it is already clean for commit.
I suggest pushing this into 8.9.x also as it is a fix and has tests.

If you want to make your drupal core maintainer life easier, you could even use cherry-pick instead of wasting time re-patching due to the branch compatibility.

git checkout 8.9.x;
git pull;
git cherry-pick 685f3a0;
git push;

@joseph.olstad I needed an 8.9 test run before cherry picking. There are changes in tests-classes between 9.1.x/9.0.x and 8.9.x and the last thing I wanted to do is backport an untested patch and break every other RTBC 8.9.x patch because HEAD is failing.
i.e. there is reason in my methodology.

Cherry-picked to 8.9.x.

Nice to see the #bugsmash initiative working together to move through the layers

@joseph.olstad fwiw for core we do git cherry-pick -x 685f3a0; which is what @larowlan did. Git then adds (cherry picked from commit 685f3a060ddaf3c78389fa275a63c7f0e9aa2f21) to the commit message - which can be helpful to understand the relationship between commit.

Makes sense, thanks!
fwiw could still cherry pick also and still amend the commit lol
anyhow, no worries do as you wish was just trying to suggest something easy lol!

This issue for 8.9.1 version

I have multiple languages (EN,DE,FR) and content moderation is enable. I have two additional status for content moderation one is (Draft, In Review) now problem is currently i have to change the status for each language. in this way quite confusion for content moderator that what left and what done. Could we do something like that content moderation we bring on global level so if its status change for one language same will be implemented for other languages.

If from German language content review status added then for all rest of languages (En, FR) it will be automatically changed the status please guide me in this

is any one guide me do i need to install patch or not?

The fix on https://www.drupal.org/project/drupal/issues/3020387#comment-13696688 looks insufficient.
Shouldn't we also consider "revision_translation_affected"?

If anyone can, I would appreciate it if you could re-open this issue.

@ueshiy: Please open a new follow-up issue for that and mark it related to this issue. Once a change like this has been committed (and backported), it's very confusing to try to reopen it. Always better to open a new issue and link it. You can comment here with the URL once it exists. Thanks!

Of possible interest, we solved this issue on our suite of sites by applying the patch found at: https://www.drupal.org/project/drupal/issues/2845144#comment-14574850