"Revision log message" only accessible with "Administer Content" permission

Looks like this is an issue with Node system (or maybe Entity system), and not Content Moderation.

It seems the field permissions are handled in \Drupal\Core\Entity\ContentEntityForm::addRevisionableFormFields, I'd need a debug more closely, but some tests for this would be good!

That only controls access to the new revision checkbox, that is by design limited.

This is checked in \Drupal\node\NodeAccessControlHandler::checkFieldAccess(), apparently the logic is that the field is visible if a new revision is created by default. Maybe that isn't actually set and just enforced through content moderation? we've had bugs that content_moderation accidently disabled that checkbox, so review your node settings and make sur it is really enabled.

Resaving the form on 8.5 might also fix it, without having to uninstall content moderation. We did actually fix exactly that problem recently. Or maybe we only fixed it for 8.6.x dev, don't remember right now.. #2865223: Node type form alter sets new revision to false on subsequent saves. It was fixed in 8.5.x too.

@guix - Interesting, thanks for the testing.

As you say it's possible to reproduce on a fresh install of 8.5.x it'd be great to get a functional test which also reproduces this. I'm happy to do this, but not sure when I'll get chance, so anyone is welcome to take a look.

This is semi-related to #2946750: Node revisions forced even if bundle not under moderation workflow.

Here's a patch and test.

@guix - Are you able to confirm this works for you?
@Berdir - Are you able to check my logic here? I'm not actually testing the revision log field, but the logic used in the access control around the NodeType's new_revision property.

I'm not sure that is necessary. We already have the logic to enforce the checkbox, it was just broken in the past and this was a result of that bug.

Also, this isn't limited to nodes, block_content_type and media_type have the same feature, but with different names for the setting.

We could think about an update function to fix them once instead of checking every time, but not sure if even that is necessary.

@Berdir - Yes, the code is there to enfoce the checkbox, but if the content type was created before Content Moderation was enabled, then revisions may not be enabled, and therefore re-saving the content type is the only way to enable. Therefore I think we need something that enables revisions when moderation is enabled.

I didn't realise block content and media had a similar setting in the bundles. I don't believe we cater for that in Content Moderation. It's not a very solid pattern in core (no interface or trait).

Yeah, we did add \Drupal\Core\Entity\RevisionableEntityBundleInterface::shouldCreateNewRevision(), but that's just for reading the value, not changing it.

Still don't really like adding more node specific code.

Maybe \Drupal\node\NodeAccessControlHandler::checkFieldAccess() could check with the actual node/entity is about to be created with a new revision instead of just checking its own default value. But not sure if the enforced new revision call is happening early enough. Likely not right now as we, until recently, had the problem that it couldn't be set back to FALSE once set...

+++ b/core/modules/content_moderation/src/Plugin/WorkflowType/ContentModeration.php
@@ -182,6 +183,16 @@ public function addEntityTypeAndBundle($entity_type_id, $bundle_id) {
+      if ($entity_type_id == 'node') {
+        $bundle = NodeType::load($bundle_id);
+        if ($bundle->isNewRevision() === FALSE) {
+          $bundle->set('new_revision', TRUE);
+          $bundle->save();
+        }
+      }

I think @Berdir is right here, if we have entity type specific code we should move that into the moderation handlers and then try provide as much of a default implementation as we can.

I think we should even go a step further and completely decouple CM code from node and block: #2847629: Move specific entity type handlers to the modules that provide those entity types..

I found in #2972361: Node type's isNewRevision can be wrong and unchangeable when using content moderation that the patch in #2911473: Selected yet disabled individual options from checkboxes element don't persist through save is applicable to this issue. The disabled checkbox is not behaving as expected.

Yes, that issue would be the proper fix, but see my comment #5 for the issue that should have worked around that issue for core? Are you sure you're on the latest version and re-saved the node type settings? The first issue might be a duplicate of that?

Edit: I'm on 8.5.3 according to composer.lock but I don't seem to have the patch from that issue. Checking history..

Yeah, looks like that patch hasn't made it into a release yet, hence my fun adventures today ;)

I can confirm the issue still persists in Drupal 8.6, and can be fixed by applying the patch from #2911473: Selected yet disabled individual options from checkboxes element don't persist through save and re-saving the node type edit form.

Also $bundle->isNewRevision() is gone in favour of \Drupal\Core\Entity\RevisionableEntityBundleInterface::shouldCreateNewRevision so that will need updating

This patch address #23. Still needs work as per #13.

Fixed the fails

if ($entity_type_id == 'node') {
Won't this only fix it for nodes but what about media, blocks, or other entity types that can have revisions?

I was experiencing this bug: the "create new revision" checked and disabled and the log message input form not available (with content moderation enabled). I've fixed going to the content type settings page (admin/structure/types/manage/XXX) and pressing the save button.

The content moderation module should automatically save the "new_revision" option of the content types managed by a workflow.

The issue is still present in Drupal 113.10. On a site with Content Moderation, editors (without administer nodes) couldn't see the "Revision log message" field, while admins could.

Setting the field new_revision: true on the moderated content types. Editors then see the field again.