Scheduled Updates does not work with Content Moderation

1. +++ b/src/FieldUtilsTrait.php
   @@ -32,12 +32,12 @@ trait FieldUtilsTrait {
   -    $fields = $this->FieldManager()->getFieldStorageDefinitions($entity_type_id);
   +    $fields = $this->FieldManager()->getBaseFieldDefinitions($entity_type_id);
   

   This would stop other non base fields from being destinations.

   We should test non-base fields if we aren't so this would cause a fail.

2. +++ b/src/FieldUtilsTrait.php
   @@ -91,16 +91,16 @@ trait FieldUtilsTrait {
   +    if ($definition->getName() != 'moderation_state' && $definition instanceof BaseFieldDefinition && $definition->isReadOnly()) {
   

   Ok so this is really tricky because both content_moderation and workbench_moderation state use the field name 'moderation_state'. So if they store their field information differently this is going to be a problem.

   WorkBench Moderation for 8.x has 2,691 install and Content Moderation is still experimental. If we could only support 1 I would say it should be WorkBench moderation until Content Moderation is stable.

   Otherwise we check which module is enabled.

@chr.fritsch that seems better!
Couple things

1. +++ b/src/FieldUtilsTrait.php
   @@ -27,6 +27,26 @@ trait FieldUtilsTrait {
   +   * @return \Drupal\Core\Field\FieldStorageDefinitionInterface[]
   

   Would this still return the same interface[]? Maybe change to FieldDefinitionInterface[]?

2. +++ b/src/FieldUtilsTrait.php
   @@ -27,6 +27,26 @@ trait FieldUtilsTrait {
   +  protected function getFieldStorageDefinitions($entity_type_id) {
   

   Then name for function would probably need to be changed.

Could you write a test? What is origin of the problem? Not being about to update a computed field? I think testing again "moderation_state" would be problem because this is still experimental right? Are there other core computed fields to test? Path?

I'm trying to test this but am unsure what I should be selecting when trying to add a scheduled update field? nothing I am seeing looks obviously related to content moderation. see attached image:

patch was applied against: "drupal/scheduled_updates": "1.x-dev#d974e68"

@realityloop do you have the experimental module "Content Moderation" enabled that was release with 8.2?

Also @chr.fritsch probably some instructions and how to reproduce and what change should see with the patch would be helpful.
Right now all we have is

This is the reason why they are not playing together.

@tedbow

Yes, Content Moderation in core.

@chr.fritsch

Thanks for the testing instructions.

Attached is a video I made of how I expect it to work from video that tedbow has created previously, however it's not behaving as I expect.

I tested both with unlimited and single for Update Limit and the result is the same.

Have I made an error in the field setup?

I was trying to create buttons for both publish and unpublish, and that it would hide the transitions on the submit dropdown like the example in tedbows earlier video.. https://www.youtube.com/watch?v=dYyWyR25tKc

edit: if I don't select a moderation state when creating the Scheduled Update field then the date form does get shown, but you then have to define what type of update this will be, which means a separate edit would be required to schedule both publication and archival of content.

I've managed to get a field created and it's usable in a way that makes sense (and is working with Paragraphs).

I'm having trouble finding where to add a pre-existing update field to newly created Node types?

Note: disregard the attached image.

So I've managed to do some fuller testing of this patch and it looks ok except that usesr with limited state transitions can still schedule any state change including those they don't have access too.

This has been working well with core 8.2.x, however I've just tested and can confirm it does not work with the changes that are in core 8.3.x

In 8.3.x the field where you type / select the moderation state does not show get a valid list of states.

The fix might also consider the need to support being at the receiving and of an entity_reference_revisions instead of entity_reference: currently, this causes this system to be mostly broken for Paragraphs.

Also seeing the same issue on 8.3.x as #18 when trying to add a Scheduled Update Type (running 8.x-1.0-alpha6).

Nothing but an Ajax - A fatal error occurred: The "" entity type does not exist.

On 8.3.x , You can create multi workflow content moderation (in 8.2.x only one). So I think This is reason patch don't work.

Did some digging into the problem in 8.3. Before 8.3 was the moderation_state field an entity reference field, but from 8.3 is it a string (FieldItemList) - not a "list_string". Thats one of the reasons why the default value fieldset is not shown. There might be other reasons too.

This is still a problem as of 8.4.3. It seems to me that the right solution with the way Content Moderation and Workflows have evolved in core would be for the Scheduled Update to trigger a transition for the entity from one state to the next instead of direct field manipulation. Does that make sense? Given that is module is built around updating values on a schedule is triggering a transition even something that should get handled in this module or is that enough of a departure to suggest that it should just be handled as a separate project?

My $.02: As Content Moderation is now part of core, I would think this continued effort would be appropriate for this module.

There is a module for that https://www.drupal.org/project/content_moderation_scheduled_updates

Patch #7 works for me @ Drupal 8.5.3

Patch #7 didn't quite work for me in Drupal 8.5.5 with default core Content Moderation workflow and Scheduled Updates (8.x-1.0-alpha7) when trying to manipulate MODERATION_STATE field change.

There was no way to set a default value for it, when configuring UPDATE FIELD on the node...

So, I was digging around a little bit to try and modify the form widget for Moderation State, and updated the patch from #7 a little. In the end, I am able to pick a default value:

I also select to HIDE moderation_state field during update, so that it works by itself (similar to Published field).

Steps:

• Clicked Add Update field on the content type in question (Manage Fields)
• Selected "Moderation state" as the Update field
• Selected default "Moderation state" value + option to "Hide" the field
• For "Reference Field Options" picked "Create new reference fields to enter updates." and configured the field Label
• Selected "Latest revision" as the runner settings
• After Update behaviour: Delete update
• Invalid Update behaviour: Leave update in queue
• Create New Revisions: Use bundle default
• Run update as: The owner of the update

I am not sure if that's the best approach, but it worked for my purposes at this time.

I added one more adjustment to this patch to make Scheduling work with revisionable custom entities.

In function supportsRevisionBundleDefault(ScheduledUpdateTypeInterface $scheduledUpdateType) where it checks whether the node implements NodeTypeInterface, I have also added the check $type_definition->isRevisionable() to account for entities that implement it.

Thank you for the patch, works for me. I would like to see it in stable version.

Thank you @veronicaSeveryn for the patch in #28. The existing patch from #28 was no longer applying cleanly so I've re-applied patch #28 against the latest -dev release. With this updated patch applied and following the steps from Comment #27 the scheduled_updates feature appears to function as expected with content moderation.

@hershy.k, I always prefer to see at least two confirmations that a patch works to hopefully increase use case coverage, but thank you very much for your reroll & assistance in getting this far.

To keep the noise down for everyone going to try and address over in #3585287: Make this work with Workbench Moderation and Content Moderation am assigning credit to the best of my ability.