Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Proposal:
Add a check for 'git vetted user' status on the 'create release' form.
Proposal:
Once we implement the proposal listed in #2453587: [policy, no patch] Changes to the project application review process, it will be possible for non-vetted users to promote one sandbox project to full project status without having obtained Git Vetted User status. We do not want these users to be able to create stable releases on their projects.
This issue proposes to update the create release form to to prevent non Git-vetted users from generating stable releases.
Remaining Tasks:
Add additional validation to the 'create release' form which checks to see if the user has the 'git vetted status', and if not, remove any tags matching 'stable' release patterns from the select box. Degrade gracefully if there are no valid tags left once the stable patterns have been removed.
Implementation Details
Implementation would likely take place in the drupalorg_project submodule within the Drupalorg Customizations module.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | 2035235-9-add-perm-for-stable-relases.patch | 2.13 KB | chrisarusso |
Comments
Comment #1
jthorson commentedComment #2
drummThis should display a message pointing to the vetting process so anyone blocked from creating releases has a way forward.
Comment #3
gisleCurrently, only tagged releases can have translations on https://localize.drupal.org/. At least for non-English users, this makes
-devonly projects very much second class.I suggest that this task is added to the issue summary:
-devonly full projects to have translations in place on https://localize.drupal.org/.Comment #4
catchWhy only -dev and not alpha/beta?
Comment #5
kattekrab commentedComment #6
drummRelease nodes don’t use the standard node permissions, so we'll be checking this directly on the create release form.
Specifically, this can be added in
drupalorg_project_form_node_form_alter(), theelseif (project_release_node_is_release($form_state['node'])) {section.Disabling the disallowed tags in the “Git release tag or branch” select field should effectively limit it. Along with messaging for this situation, it should help people know when they have tagged something correctly, but don't have access.
This should be a new permission and a check for the permission. (Hard-coding specific roles has not gone well in the past.) The role that gets the permission should be exported in
drupalorg_permissions.Comment #7
jthorson commentedUpdated issue summary to reflect 'not creating stable releases' versus original 'only creating dev releases'.
Comment #8
drummComment #9
chrisarusso commentedFirst off, big thanks to @jthorson, and @drumm for the assistance and back and forth at the sprint at Drupalcon on Friday.
After running into the weird caching issues on the staging/dev server today that I was warned about on Friday ;) I was able to get this mostly working as expected
Notes from the associated patch/approach.
We originally were hoping to simply disable form elements but we realized this was not easily workable with the Drupal Form API, so as a group we agreed to just remove the options from people who are NOT git vetted users.
I have put several @todos in the code that correspond to review and/or updates to actually creating the permission as discussed earlier in the issue.
FWIW:
Comment #10
chrisarusso commentedComment #11
drummLooks like a good start.
For initializing the classes, I think this should more-closely match the code for loading tags in
versioncontrol_release_get_possible_labels().Comment #12
fuzzy76 commentedComment #13
drumm#2787165: Add security advisory coverage field to projects replaced the need for this. Rather than the gate being on security-team-supported full releases, we can now gate on ability to opt into support.