When trying to fix a botched release in ctools, I mistakenly unpublished the 4.0.0 release, thinking it would stop recommending it, but not remove it entirely. This was different from an earlier incident years ago at the drupal association when a tag was deleted.
We have automatic ways to stop tags from being deleted, but there is no warning or indication that unpublishing a release has the same effect. Site moderators get a warning regarding security releases as well, to only use them in consultation with the sec team.
drupalorg_permission(), add a new administer all releases permission with title “Administer all releases” and description “Edit and change published status of all releases”#access on the published status checkbox to user_access('administer all releases')drupalorg_node_access(), if $op is 'update' or 'delete', and project_release_node_is_release($node), deny access if the user does not have that permission. Do allow update access if the user is a project maintainer project_user_access($project_nid, 'administer releases')
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
avpadernoComment #3
drummI actually can’t think of a valid reason for any site moderator to unpublish any release. They might not even need edit access. Let’s start with removing site moderator release edit access. We can always adjust this later, if there’s some use case I’m not thinking of.
We will also have to remove access to the publish/unpublish checkbox on the release edit form. In this case, you did have edit access as a project maintainer. Site moderator access should not allow changing the published status in this case.
Comment #4
drummSite moderators currently have the “administer nodes” permission. We should review the goals of the role, and tasks expected. That will help decide if that blanket permission should be swapped for the more-fine-grained permissions, or if we keep “administer nodes” access and add additional custom access alterations.
Comment #5
japerryWhat about fixing typos or adding information to the release notes on a release node?
Otherwise I agree that there shouldn't be any need to unpublish a release if it's effect is the same as deleting a tag, which shouldn't/cannot be done already.
Comment #6
drummI’d think adding information to release notes would only ever be done by a project’s maintainer. If you aren’t the maintainer of the project, you should file an issue to request that they update the release notes.
Comment #7
japerryOhh yes, I misunderstood the original message. The only reason why a site moderator would need access is if someone put things in the release notes that violated CoC, security, or other rules. But since that is pretty rare, and would probably lead to a bunch of other issues, its probably safe to delegate those issues to DA staff only anyway.
Comment #8
drummSince there are a few roles with administer nodes, and this should apply to all of them. We should keep “administer nodes” access and add additional custom access alterations. I’ve updated the issue summary with the changes that should be made.
Comment #12
fjgarlin commentedImplemented the proposed resolution and the code is ready to review.
I disabled the "published" checkbox instead of hiding it as there is some core javascript that expects it to be there and if it's not, it'll say "Not published", regardless of the actual value.
Comment #13
japerryFirst pass of this looks good, is there site accessible to test this change? Another option, if the disable function has issues, is to put a check during the validate phase. Since this option would only be accessible by those with 'administer content', the typical UI weirdness of "cannot unpublish a released node" after save wouldn't be that bad.
Comment #14
fjgarlin commented@drumm - All feedback in the MR was addressed.
@japerry - https://fjgarlin-drupal.dev.devdrupal.org/ and then edit any release. In this instance and just for testing, the new permission has been given only to "Site moderators".
Comment #17
drummThis is deployed now. Thanks!
Comment #18
japerryYup, I can verify that its working on prod. thanks all.