On the entity form of revisionable entities, make "create new revision" and "revision log" configurable

This is highly dependent on #2490136: Enable revisions by default, once that gets committed I'll write the patch for this.

I think this belongs in "Workflow Initiative", also noticed that 5 months ago I promised to write the patch, I re-add it to the todo list.

What will happen with the revision log field? I guess it would simply stay where it is?

Added an initial patch for removing the checkbox and save the revisions by default. I guess it needs test.

1. +++ b/core/modules/node/src/NodeForm.php
   @@ -317,16 +309,11 @@ public function submitForm(array &$form, FormStateInterface $form_state) {
   +    // If a new revision is created, save the current user as revision author.
   

   This comment is out of date. Maybe we can just add "and set the current user as the revision author." to the previous comment

2. +++ b/core/modules/node/src/NodeForm.php
   @@ -317,16 +309,11 @@ public function submitForm(array &$form, FormStateInterface $form_state) {
   +    $node->setRevisionCreationTime(REQUEST_TIME);
   

   This should now use \Drupal::time() since we're changing it here anyway. Changing it to inject the dependencies would be out of scope IMO, but this change should be fine.

Copy & paste of my comment in #2669802-50: Add a content entity form which allows to set revisions

I'm not 100% convinced yet. I think there are sites that might want to give users a choice. Especially with translations and so on, there are IMHO valid use cases to avoid saving new revisions.

From that issue:

The decision to save new revisions or not is a site building or developer issue, not a content author one.
Maybe, but why don't we let the site builder/developer decide what they want to allow?

Note that at least for nodes, you already need administrative permissions to change the default (which means you can also publish/unpublish, change author, ...), so this permission already exists to allow them that kind of control. But it is global. We could add another setting to the node type to control if the setting should be enforced or not?

Based on a short discussion in IRC with @catch, I provided another reason why a setting would make sense to me: We can add that any time in 8.x, we could even default it to TRUE (enforce setting) for new node types as long as we force it to FALSE in an update function for existing ones.

That allows sites that want to enforce this to do it now, and we can still see if we want to remove that setting again in 9.x and enforce it (while still allowing form alters or so to change it I suppose). Maybe those examples that I have in mind (like fixing a typo in the default revision while other changes are being worked on in forward/draft revisions or translation related things) will not longer be valid when we have improved UI's, workspaces and so on (Where users don't have to chose between creating a revision or not but between saving and saving as draft/other workflow state or something).

I agree that site builders at least should have a choice to enable the checkbox for authors. Not sure about the default setting? Maybe UX people can comment on that.

Are we talking node form only or "everywhere" and if the latter, what does that mean? :)

It would be nice if we have a consistent UX for all revisionable entity types. For now I think it's just node and block content in core.

I agree that this is more of a site builder task to implement what's probably a *business* decision (about governance, compliance etc.) of whether to expose revision checkboxes to content authors. I think the default should be "on" so that it provides a kind of safety net for content changes.

If i get it right the consensus here is (#13):
> We could add another setting to the node type to control if the [create new revision] setting should be enforced or not?

Setting title accordingly.

Also we have other related issues about (see related):
* Should the "revision log" field be provided
* Should (Add new revision | Revision log) be available on node-create or only on edit
(We can reasonably assume that "show on create but not on edit" does not make sense.

My feeling is that rather than splitting this into 2^n issues, let's handle this here "once and for all"(TM).

Sounds like a plan, thanks @axel.rutz

So when we want to configure
* Should the "revision log" field be provided
* Should (Add new revision | Revision log) be available on node-create or only on edit

...and we have these means of configuring:
* node type form
* form mode fields
* permissions

...i'd propose to do it like this:
* Make Override if a revision is created for node type foo a permission (which prevents the Add new revision checkbox)
* Make Add new revision and Revision log fields configurable per form-display. This opens the possibility to have them on one form mode and not the other.
* Make Show 'Add new revision' and 'Revision log' also on node create (not only on node edit) form" a setting per node type

Oh, even more related issues...

We already changed a while ago to not show the revision on node create, that's not up for discussion. A setting simply doesn't make sense because a new entity is always a new revision. In the past the setting was shown but was not relevant.

We currently already have a permission to control if the checkbox can be changed or not, that's administer nodes. While splitting that up would be useful, I don't think it belongs in this issue.

IMHO, this is really just about introducing a setting whether the new revision checkbox should not be visible at all, even for users with that permission. I disagree that trying to do multiple things here will make it easier to get it done, usually those kind of issues get stuck in discussions forever.

I think on the content type edit form (/admin/structure/types/manage/article), maybe under "publishing options" we first remove the "Create new revision" checkbox. Then add checkboxes for "allow content authors to choose if a new revision is created", "allow content authors to add a revision log"

The create new revision checkbox should never show up on a new node form, because a new node will always be a new revision, but I think the revision log field should be shown on new and existing nodes.

crosspost

The contrib solution to the original request (remove the checkbox) is Hide Revision Field: https://www.drupal.org/project/hide_revision_field

Its respectable usage statistics, despite being harder to find than this issue, indicates interest in removing this clutter from the authoring experience.

+1 to always doing revisions and hiding the log message textarea by default (or even letting contrib add it back)

I created this issue #2978701: Replace the revision log message with a comment field. I'm not sure if this is a solution for this issue, but if revision log messages were a comment field site builders could at least decide what comment fields are mandatory or if all fields in the revision log will be hidden. So it will give site builders a lot of possibilities to configure the behavior they want.

Let's make sure this is consistently solved for all revisionable entity types.

The fact that a D8-only contrib module has more than thousand installs points to this being a major UI annoyance or, as the contrib maintainer says, "noise."

The decision to save new revisions or not is a site building or developer issue, not a content author one.

Full ACK.

What about making that "revision log" configurable by form display?

What about making that "revision log" configurable by form display?

I love the idea in principle, but we need to handle its relationship with the "Create new revision" checkbox.

Do we really have a relation?

So what we could create is an extra field "Create new revision" that appears on all the form displays, next to "Revision log message".

In that case, the site builders have the maximum freedom.

As an alternative, we could create an extra field "Revision information" that combines the checkbox and the log message.

Do we really have a relation?

If per #26 we persist in having a checkbox to "allow content authors to choose if a new revision is created" then
1. we should only show/enable the revision log field if they check that
2. we would likely want to place the revision log immediately under that checkbox

So what we could create is an extra field "Create new revision" that appears on all the form displays, next to "Revision log message".

As an alternative, we could create an extra field "Revision information" that combines the checkbox and the log message.

Extra fields don't have settings so with extra fields along we wouldn't have the ability for the sitebuilder to force the creation of new revisions but allow the editor to give a log message, or for the sitebuilder to allow the editor to choose whether a revision is created but not allow the editor to give a log message?

How about either:

A: Create depends on log
1) Create a bundle setting "Always create new revision"
2) Make the revision log form display configurable as you suggested in #36
3) If the setting "Always create new revision" is false, then create a new revision only if there is a log message

B: Use a widget
This is how the contrib module does it.

Is there any update on this? I have recently created a site that allows users to register and post job announcements. On the job content type edit page I have unchecked the box to create a new revision, and this successfully removes that field from the create new node form. But the revision field remains on the edit node form, and it seems impossible to remove. That is a field that my users do not need to see and it seems crazy this wouldn't be configurable by the site builder.

There are configurable permissions to delete revisions, revert revisions, and view revisions... Why not simply make a permission for user roles to create revisions? When unchecked for a certain user role, the revision field would not display on node add/edit forms for the content type.

Also, revision log field weight is hardcoded and cannot be altered via hook_form_alter due to another issue #3056053: Not possible to change weight of entity form field widget in hook_form_alter().

Looks like something has changed and the "Create new revision" is now visible even for users who don't have the administer nodes permission. Filed issue for that: #3384520: "Create new revision" is overridable regardless of permissions.