Add a check for 'git vetted user' status on the 'create release' form.

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.

Membership dollars fund testing for the Drupal project. Drupal Association Learn more


jthorson’s picture

Project: ProjectApps Customizations » customizations
Version: » 7.x-3.x-dev
Issue summary: View changes
drumm’s picture

This should display a message pointing to the vetting process so anyone blocked from creating releases has a way forward.

gisle’s picture

We do not want these users to be able to create anything more than a -dev release on these projects.

Currently, only tagged releases can have translations on At least for non-English users, this makes -dev only projects very much second class.

I suggest that this task is added to the issue summary:

catch’s picture

Why only -dev and not alpha/beta?

kattekrab’s picture

drumm’s picture

Release 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(), the elseif (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.

jthorson’s picture

Issue summary: View changes

Updated issue summary to reflect 'not creating stable releases' versus original 'only creating dev releases'.

drumm’s picture

Title: Add a check for 'git vetted user' status on the 'create release' form » Add a permission for creating stable releases, and grant to “git vetted” users
chrisarusso’s picture

First 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.


chrisarusso’s picture

Status: Active » Needs review
drumm’s picture

Status: Needs review » Needs work

Looks 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().

fuzzy76’s picture

drumm’s picture

Status: Needs work » Closed (works as designed)

#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.