If a node type's 'Create new revision' is enabled and the $user does NOT have 'administer nodes' permission, she cannot edit the nodes of this type without creating a new revision, regardless the fact that she is granted the 'delete revisions' permission. IMO if the $user is allowed to delete revisions, then she should even be allowed to edit the nodes without creating a new revision.

I was even thinking about taking the 'revert revisions' permission into account. If the $user is only allowed to revert revisions, but not delete them, then she is not allowed to hide her own edits from the history, so granting her the 'revert revisions' by itself should not allow her to edit a node without creating a new revision. OTOH if she is granted the 'delete revisions', but not the 'revert revisions' permission, then she can hide the fact that there was a revision before her own one, anyway.

In short, it is kind of usability improvement: allow the $user to edit a node without creating a new revision if she can hide the fact that there was any previous revisions before her own one (by deleting the old ones). The attached patch does this.

Files: 
CommentFileSizeAuthor
allow_unrevisioned_edit_with_delete_revisions.patch817 bytesBoobaa
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch allow_unrevisioned_edit_with_delete_revisions.patch. Unable to apply patch. See the log in the details link for more information. View

Comments

Boobaa’s picture

Title: Allow unrevisioned node edits when $user can revert/delete revisions » Allow unrevisioned node edits when $user can delete revisions

Oops, forgot to correct the title when I was thinking about the thing again before submitting. Sorry.

ff1’s picture

Version: 7.x-dev » 8.x-dev

Bumping to D8...

kscheirer’s picture

Status: Needs review » Needs work

The last submitted patch, allow_unrevisioned_edit_with_delete_revisions.patch, failed testing.

xjm’s picture

Component: node.module » node system
Issue summary: View changes

(Merging "node system" and "node.module" components for 8.x; disregard.)

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

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

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.