Unable to Publish/Unpublish from Content Admin Screen when content_moderation enabled

@Sam152 yep this needs tests so needs work...

Nice find @gcb

I don't get the body of the access check to be honest, it reads:

->andif(AccessResult::forbiddenIf($this->moderationInfo->isModeratedEntity($object))->addCacheableDependency($object));

Why would access to the plugin be denied if the entity was moderated? The whole point of it is to provide a nice message to the user as to why their entity can't be published/unpublished as a bulk action.

Before and after:

I think the approach of removing the access constraint based on if the entity is moderated or not is the right move, happy to be proven wrong. Attached is a fix based on that approach and a test.

I guess the test should also make sure bundles that aren't moderated behave normally and that the action itself transitions the published state correctly for each scenario.

Just been testing out this patch it's not very good UX. It doesn't seem clear what's going on.

I think this patch makes things better than HEAD, but I think it could be better again. Maybe list which entities could not be published, and which could not be unpublished. Then explain how to publish / unpublish them.

Maybe we need actions for moderation states so you can bulk publish / unpublish entities?

#2753157: Expose workflow states and status as selects in /content has a design for what this interface might look like. I don't mind blocking/postponing behind that, but as #11 points out this just fixes a bug with existing behaviour.

Hit this again personally. I think we should fix the bug and address the UX issues in a follow up, given this breaks publish/unpublish for ALL node types regardless of CM being enabled. UX changes are likely to be way bigger in scope and can be derailed easier than a simple bugfix.

I think it still might be good to add a bit more context to the Drupal set message. Was it one entity? or more? how many was it? which ones? which bundles / content types?

Could we say "All Article Nodes were skipped as they are under moderation and may not be directly published or unpublished."? Or "Three Article Nodes were skipped as they are under moderation and may not be directly published or unpublished."?

Even replacing entities with Nodes would help.

Mentioning the bundle sounds like a really good idea.

Quite a big rewrite, changing this to hook into the access handler and adding the bundle label in the warning.

I ran the tests and these are the messages that show up using the access approach, although I do like the bundle being in the message.

The fail is a bug that must have been introduced since #7. Opened #2839371: Programatically creating a published entity doesn't result in a published entity. for it.

Just thinking about this, we shouldn't use the term "nodes" here, we should use 'label_singular' or 'label_plural'.

Here's a patch that should now pass tests.

I think the "no access" message shown in #22 is better than the "published" message shown in #6, shown when nothing was published.

Yay, finally passing.

Committed 4739b5c and pushed to 8.3.x. Thanks!

diff --git a/core/modules/content_moderation/tests/src/Functional/ModerationActionsTest.php b/core/modules/content_moderation/tests/src/Functional/ModerationActionsTest.php
index ec87f78..32d10fa 100644
--- a/core/modules/content_moderation/tests/src/Functional/ModerationActionsTest.php
+++ b/core/modules/content_moderation/tests/src/Functional/ModerationActionsTest.php
@@ -4,7 +4,6 @@
 
 use Drupal\node\Entity\Node;
 use Drupal\simpletest\ContentTypeCreationTrait;
-use Drupal\simpletest\NodeCreationTrait;
 use Drupal\Tests\BrowserTestBase;
 use Drupal\workflows\Entity\Workflow;
 

Fixed on commit.

Is it worth backporting this to 8.2.x?

Is it possible to backport the code to 8.2.x branch?

@podarok - You're welcome to port it back, but a lot has changed between 8.2 and 8.3 for Content Moderation, so didn't seem worth it.

@timmillwood are any of these patches applicable to 8.2.x? I ran into this issue of not being able to unpublish nodes after sending them all the way up the moderation chain (draft, review, editing, approved, published, archived) only to find out that I can't unpublish a node if I realize some mistakes that didn't get caught during the review phase.

Is the Workflow contrib more stable than Core Content Moderation at this point for 8.2.x?

@wesleymusgrove - The patch should work fine in 8.2 apart from the test IIRC.

There are experimental modules, so there is no upgrade path, and we may change things. So it may be safer to use Workbench Moderation, however we've fixed many issues in Workbench Moderation when porting to Content Moderation.

I applied the patch on 8.2.x and it did not applied correctly so I altered the patch.

workbench_moderation 7.x-3.x has same issue due to dependancy on drafty which appears to be similar approach to what is done in D8.
patch available here:
#2910310-10: drafty allow publishing current draft from /admin/content page when node already published when Workbench Moderation 7.x-3.x is enabled

Hi all,

I'm getting the same error on 8.4.0:

Has something rolled back between 8.3 and 8.4?

Cheers,
Jesse.

Re: #41 are you saying some of those items of content do not have a moderation workflow applied to them? If they all do, it's behaving correctly by protecting them from being directly published/unpublished.

@Sam152 yes they do. Isn't the problem that you're prevented from directly publishing from /content/admin/? If that's supposed to be the outcome, that's not very useful, especially as a site admin. At the very least there's a UX/UI issue in that the 'actions' drop down has 'publish' as one of the options. If that's not possible, it shouldn't be there.

How do I bulk publish content with content moderation on? Do I really have to push each item through a workflow?

The primary issue is, in a view of nodes only certain bundles might be moderated, so removing the action entirely would cause you to lose that feature for rows where it makes sense.

Do I really have to push each item through a workflow?

Exactly right, when applying a moderation workflow, we want to make sure content actually goes through those transitions. It would be an access bypass for example if a user with only the "put something in review" permission could publish that content outside of the moderation workflow.

An issue worth pointing out is: #2797583: Dynamically provide action plugins for every moderation state change. The goal there is to represent each one of the states as an action, so the bulk tools can be used in combination with a moderation workflow.

So I wonder what one must do if they have hundreds of nodes which need to be published.