Posted by matteogeco on December 15, 2008 at 11:36am
| Project: | Project |
| Version: | 6.x-1.x-dev |
| Component: | Releases |
| Category: | bug report |
| Priority: | normal |
| Assigned: | dww |
| Status: | closed (fixed) |
Issue Summary
If you enable "Project releases" after creating a project and then add a release to the project, the releases download table won't show up.
Reproducibility:
- Enable "Project"
- Create a project
- Enable "Project releases"
- Add a release to the formerly created project.
The "download table" doesn't show up in the project view page.
It' releated to the fact that the module creates the record in project_release_projects only when a project is first created.
Comments
#1
Yup, I can reproduce this. Definitely a bug. Related to #104190: Submit issues cannot find projects but in this case for the {project_release_projects} table. :( We should make sure {project*_projects} does this right once and for all. Any project-module add-on (project_release, project_issue, etc) that has its own "projects" table should populate records for all existing projects when the add-on is first enabled.
#2
This seems better than trying to just do it all at once when project_release.module is enabled, and it'll solve the problem on sites that are already experiencing the bug.
In terms of this same bug hitting other parts of project*:
- project_issue is already "fixed" (although I think I'd be in favor of porting this change to project_issue, too).
- project_usage doesn't have its own "projects" table.
- cvs.module does its own slightly weird thing to solve this -- in cvs_nodeapi() for both 'insert' and 'update', it always deletes any existing row in {cvs_projects} and inserts a new one.
#3
Ported the same idea to project_issue, and added code comments. Pretty sure these are RTBC.
#4
That's a good start guys, but still, if you execute my steps, the table won't show up.
To make it appear you must go to "Administer releases" an click submit, while, if you enable the module at the "right" time, the table will appear as soon as you add the release!
#5
Hrm, ok. I hadn't actually tested your steps, I was just looking at the ability to save the version string format string, for example. I'll give this another look for exactly what you describe.
#6
Here is a patch which addresses #4.
With the patches by Derek in #3, this should fix this bug for good.
I'm also attaching a minor patch for
project_issuewhich removes the call toproject_issue_add_missing_projectsfromhook_installsince it's called inhook_enableanyway.#7
#8
Attempted summary:
- We need #6 (check during hook_enable()) so that the bug is fixed if you just enable a submodule but don't edit any existing projects for that submodule.
- We need #3 (insert a record if we fail to update one during edit) for sites that already have some projects in the funky state, and try to edit, without enable/disable.
@alienbrain: is that accurate? I didn't check, but do all these patches apply to both D5 and HEAD?
Thanks!
-Derek
#9
Argh, I can't believe this issue is still open... I was just hit by this on a Project* site where I had to turn on project_release for the first time.
I ported both #3 and #6 to D6 of project_issue and project_release, then committed everything to both HEAD (6.x-1.*) and DRUPAL-5--2 for project_issue and DRUPAL-5 for project_release.
#10
Automatically closed -- issue fixed for 2 weeks with no activity.