Problem/Motivation

When creating a new entity with the default editorial workflow it would be expected the available transitions are the ones from draft (to draft or published), however it looks as though the ones from published (to draft, published, or archived) are being used.

Proposed resolution

Make sure the current state in \Drupal\content_moderation\StateTransitionValidation::getValidTransitions is correct for new entities.

Remaining tasks

User interface changes

API changes

Data model changes

Comments

timmillwood created an issue. See original summary.

timmillwood’s picture

Issue summary: View changes

It looks as though the current state in \Drupal\content_moderation\StateTransitionValidation::getValidTransitions is published, when it should be draft.

timmillwood’s picture

I think this issue was introduced in #2817835: When enabling moderation apply a relative state.

timmillwood’s picture

Status: Active » Needs review
StatusFileSize
new824 bytes

Initial fix, also need to check this works with translations.

Status: Needs review » Needs work

The last submitted patch, 4: 2884715-4.patch, failed testing. View results

timmillwood’s picture

Status: Needs work » Needs review
StatusFileSize
new1.87 KB
new2.67 KB

This patch updates the test, which was wrongly changed in #2817835: When enabling moderation apply a relative state, it also adds a test of an unsaved entity, thus the entity which would be used on a new node form.

sam152’s picture

We decided in #2839371: Programatically creating a published entity doesn't result in a published entity. that entities would always start their life as a draft regardless of published status, so liking this bugfix.

I think the only change I would make would be to move testing this to \Drupal\Tests\content_moderation\Kernel\InitialStateTest::testInitialState. The test methods "testArrayIteration" and "testArrayIndex" don't really fit, but we can safely update the values in that test from 'published' to 'draft'.

Otherwise, I think this is good to go.

timmillwood’s picture

Issue tags: -Needs tests
StatusFileSize
new2.49 KB
new2.66 KB

Moved the presave node test to InitialStateTest.

sam152’s picture

Status: Needs review » Reviewed & tested by the community

LGTM. Failing test will help committers.

larowlan’s picture

Can we get a test-only patch here? Thanks.

Assuming we end up with red/green - looks good to me.

tstoeckler’s picture

Status: Reviewed & tested by the community » Needs review
+++ b/core/modules/content_moderation/src/Plugin/WorkflowType/ContentModeration.php
@@ -331,7 +331,7 @@ public function getConfiguration() {
     if ($entity instanceof EntityPublishedInterface) {
-      return $workflow->getState($entity->isPublished() ? 'published' : 'draft');
+      return $workflow->getState($entity->isPublished() && !$entity->isNew() ? 'published' : 'draft');
     }

Does the ->isNew() check make sense also for entities not implementing EntityPublishedInterface?

larowlan’s picture

So in those instances (e.g. Block Content in core) it would fallback to the parent implementation, which picks the first state in the workflow.

Is that appropriate?

timmillwood’s picture

Right, before #2817835: When enabling moderation apply a relative state all entity types would use the first state in the workflow. The patch in that issue changed the logic to use the published state if the entity is published, but still the initial state for entity types that can't be published. This issue doesn't change that.

All this is doing is changing the initial state for new entities to draft because in content moderation we treat new entities as unpublished, where as core treats new entities as published.

Therefore I think this is the correct behaviour and should go back to RTBC.

tstoeckler’s picture

Status: Needs review » Reviewed & tested by the community

Can't say that I fully grok all the details there, but @timmillwood being confident about its correctness works for me. Patch in general looks good and was already RTBC-ed before. Thanks for the confirmation.

gábor hojtsy’s picture

Status: Reviewed & tested by the community » Needs work

@larowlan's request in #10 was not answered unfortunately. Should be easy to do though :)

timmillwood’s picture

Status: Needs work » Needs review
StatusFileSize
new1.86 KB
new2.66 KB

Test only patch and a re-upload of #8.

The last submitted patch, 16: 2884715-test-only.patch, failed testing. View results

timmillwood’s picture

Status: Needs review » Reviewed & tested by the community

Test only patch fails as planned, so back to RTBC.

  • Gábor Hojtsy committed f4951f7 on 8.3.x
    Issue #2884715 by timmillwood, Sam152, larowlan, tstoeckler: Initial...

  • Gábor Hojtsy committed 69555bc on 8.4.x
    Issue #2884715 by timmillwood, Sam152, larowlan, tstoeckler: Initial...
gábor hojtsy’s picture

Status: Reviewed & tested by the community » Fixed

Discussed with @larowlan and he was ok as well. Thanks for the fail patch :)

gábor hojtsy’s picture

Version: 8.4.x-dev » 8.3.x-dev

Status: Fixed » Closed (fixed)

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