On a number of 'full projects', the 'field_project_has_releases' checkbox is not checked; and releases can not be enabled because the checkbox is only visible to admin users.
This may be true of any sandbox project which has been promoted to a full project since the Drupal.org D7 upgrade was launched. I believe that there is an 'enable releases' checkbox available on the promotion form, but if this was not set during promotion, the project is then stuck in a 'no release' state.
Proposed Solution
A patch has been posted below which would make the checkbox visible to project maintainers with the appropriate level of access on the project. This will allow maintainers to correct the condition on their own projects.
Original Report:
I promoted https://drupal.org/project/message_subscribe_email_frequency to a full project and can't seem to enable releases. I've followed the instructions here: https://drupal.org/node/1068944
However, when I go to Edit > Releases, I don't see any place to enable releases. See the attached screenshot for what I see. Then, if I click the "Add new release" link, I get a "Message Subscribe Email Frequency does not have project releases enabled.", which makes sense since I haven't enabled releases yet.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 2132003_re-enable-project-has-release-field-access_v3.patch | 3.6 KB | dww |
| Screenshot from 2013-11-08 18:53:46.png | 73.92 KB | anemirovsky |
Comments
Comment #1
jthorson commentedI guess this was a change from D6 to D7 ... the checkbox would appear under the 'Releases' vertical tab at the bottom of the project edit page, but the current logic is that all full projects have releases enabled by default. Therefore, the checkbox is 'hidden', and forced on for full projects (and off for sandboxes).
It sounds as if this setting on your project somehow lost the value of this checkbox ... we'll need to look into the db to verify.
Comment #2
jthorson commentedFor some reason, the project lost its 'project has releases' value between revisions 6677129 and 6690591 of the project node.
Do you happen to know what (if anything) was changed during those last two revision edit/saves?
Comment #3
tvn commentedEnabled releases for the project manually.
Comment #4
kscheirerThis also affects at least some projects in the new project application queue. Typically these are sandboxes created before the D7 upgrade, that are now (after D7 upgrade) able to promoted to full projects. The applicant promotes her new module, but is unable to create any releases due to the missing "enable releases" checkbox.
This is known to affect:
Comment #5
jthorson commentedThe logic in drupalorg_field_access indicates a change from D6 to D7. The code restricts access to the 'field_project_has_releases' checkbox except for admins, to ensure that only admins can disable releases or issue queues on a project ... which in turn, prevents maintainers from enabling them. This patch should add access for maintainers with appropriate permission on a project, but still prevent them from disabling releases once a release has been created (or disabling issue queues once they've been enabled).
The code in project_release_node_validate() handles access to the field for sandbox projects, so we don't need to include it here.
Comment #7
jthorson commentedIgnore the testing status ... wrong project.
Comment #8
jthorson commentedNeed to reference $form_state['node'] instead of $form['node'] ...
Comment #9
jthorson commentedComment #10
jthorson commentedComment #11
jthorson commentedOkay ... given that the project promotion form has a checkbox which states "Enable releases (this can be changed later)", I'm going to say that hiding the release checkbox is the wrong approach, and we should go with the strategy in #8.
Comment #12
dwwSadly, when loading maintainers for a project, we don't currently try to create an owner case that has all perms, so the kind of check in v2 won't work for the actual project owners. I'll try this version on my dev site and make sure it'll work. Also, fixes a code comment that didn't match the code for a permission name.
Personally, I think we don't want to disable these checkboxes, but we can leave that for another issue.
Thanks!
-Derek
Comment #13
drummI committed http://drupalcode.org/project/drupalorg.git/commit/5f7c440, which does have minor changes.
(Part of removing the checkboxes instead of disabling was a confusing QA issue about the revisions "tab" being shown, or not. There have been a few issues. If a vertical tab is empty, it is removed. That simplifies the UI, but maybe too much. And the page has a revisions local task too, which one of or more of those issues were actually about. Simply "tab" should be a banned word in Drupal, it is not specific enough.)