New translations for moderated nodes are not created in the initial workflow state

Problem/Motivation

We 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")

Steps to reproduce

1. Enable the Content moderation and Content translations modules, and their requirements.
2. Add another language to the site.
3. Enable translation for Content (nodes) for at least one content type.
4. Enable the Editorial workflow for at least one translatable content type.
5. Configure the workflow with the 3 states listed above (draft, needs review, published), and 4 transitions:
   1. draft -> draft
   2. draft -> needs review
   3. needs review -> draft
   4. needs review -> published
6. Configure 2 roles:
   • author (with permission to use draft -> draft and draft -> needs review transitions)
   • editor (with permission to use all of the above workflow transitions)
7. An author has created a node in English, and sets it to "needs review".
8. Now the author wants to add a translation for this node. They go to the Translate tab and click on the "Add" Button.
9. The form where they can edit the node and add the german texts is displayed.
10. When they click "Save", they 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 treated as new nodes and therefore be created as "draft"?

Proposed resolution

Preserve the existing behavior for BC, but add a way to configure this when defining a workflow.

Whatever new UI is introduced should only be visible if both Content moderation and Content translation modules are enabled.

Option A

Rejected.

• Have a simple toggle for the current behavior vs using the default moderation state.
• UI is just a checkbox. Have to word it carefully to be clear.
• Setting is a bool. ID and other details TBD based on UI.

Example UI:

[X] New translations use default moderation state.
(If not checked, new translations will use the current state of the default revision).

The big problem with this approach is that folks configuring a workflow wouldn't have any idea what happens if they don't select the box unless there's a description to accompany it.

Option B

This is the winner!

• Have a simple toggle for the current behavior vs using the default moderation state (same as A)
• UI is 2 radios.
• Setting stores a string, ID would be 'translation_default_moderation_state_behavior' or so, with values like 'current' vs. 'default'.
• In some UIs, explicit radios for different options can be more clear than a checkbox (if each choice requires a little explanation).

Example UI:

Initial moderation state when adding a new translation:
(*) Default moderation state
( ) Current moderation state of the original content

Option C

Nope.

• Store the explicit moderation state for new translations.
• Setting ID would be 'translation_default_moderation_state' or so.
• Allow it to have a magic value that means "the current moderation state of the default revision in the original language".
• UI might be weird / complicated.
• Would be more powerful for edge cases.

Open questions

1. Which UI is best for the setting? Option B - radio buttons. See #45
2. Since all the code handles no value for this setting as if you want the current behavior, do we need an upgrade path and all that complication? Yes (@larowlan in #42)
3. Do we want to add this setting to the default workflows shipped with core? YES
   1. core/profiles/standard/config/optional/workflows.workflow.editorial.yml? YES
   2. If so, should we set it to 'default' or 'current'? Using 'current' per @larowlan in #42
   3. Also demo_umami? YES
4. Does this issue need a CR? YES: https://www.drupal.org/node/3240957
5. Do we need more test coverage? YES:
   1. Do we need to test the UI for this setting when configuring a workflow? YES (per @larowlan in #44). DONE in patch #47
   2. A kernel test covering the scenario in the issue summary YES (per @larowlan in #42). DONE in patch #47
6. Should the #default_value for these radios use 'default' for new workflows? It's now defaulting to 'current' if missing from the config for BC on existing sites. But presumably we could notice when creating a new workflow and use a different #default_value to be the more intuitive 'default'. NO, leave it as 'current' (per @larowlan in #42).
7. Where is the right layer of the entity / translation / content_moderation systems to specify the default moderation state of a new translation? See comment #33. We don't want to have to rely on field widgets to enforce this setting. It'd be better if we directly changed the moderation_state when populating a new translation so that field widgets don't need to support this setting, and so it works if there is no widget for moderation_state. Should we?
   1. Use hook_entity_translation_create() YES.
   2. Directly hack EntityOperations::updateOrCreateFromEntity()? This seems problematic since we'll have a hard time knowing if the entity has a value from a widget or if its own override logic should kick-in. NO
   3. Other?

Remaining tasks

• Answer the open questions.
• Implement the new setting / UI.
• Don't check if the user has access to this transition (because it should be treated as new).
• Add a DB update for existing sites
• Add tests:
  1. What you see when creating a new translation (the bug)
  2. The two different roles case described in the summary. Done in #47
  3. The upgrade path
  4. The UI for this when creating a workflow. Done in #47.

User interface changes

A new setting when creating/editing a workflow:

Before

What you see without the patch applied, or when content_moderation is enabled but content_translation is not, at paths like /admin/config/workflow/workflows/manage/editorial:

After

With the patch applied, and both content_moderation and content_translation enabled:

API changes

None.

Data model changes

New config schema for a setting on workflow type plugins.

Release notes snippet

TBD.