1) enable project, project_release and cvs modules
2) create a HEAD release node
3) don't have the packaging script exist/run
4) edit the release node
at this point, i think you'll still see a file upload UI. instead, you should just see a #markup message about "The packaging script has not yet run, there is no file for this release yet." or something.
see function cvs_alter_project_release_form_edit() for the culprit. it should be doing a check for if the file exists (in {project_release_nodes}), and if not, alter the $form['file'] accordingly (namely, unset() it and add a simple #markup as i suggest above). should be pretty easy if someone else wants to roll a patch. ;)
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | cvs_edit_release_no_file_upload.patch.txt | 804 bytes | dww |
Comments
Comment #1
AjK commentedsubscribe
Comment #2
AjK commentedQuestion: The file_path (project_release_nodes.file_path) field appears to be absolute to the drupal base path (for example files/projects/autologout-5.x-1.1.tar.gz). Should they not be relative to file_directory_path()?
I came across this when coming to do the file_exists() on the release node's file.
Comment #3
dwwoh, probably. ;) that's legacy code from the dark ages that i never cleaned up during the conversion to project_release.module. however, that's really a separate issue. if you care to fix it, please:
a) create a new issue
b) include a DB update function to convert existing data
c) include the DB update and the diff to the code in the same patch file
;)
thanks,
-derek
Comment #4
dwwbumping priority because of issues like http://drupal.org/node/129040 *sigh*
Comment #5
dwwwe don't really want to look at the file on the filesystem (a real file_exists(), like ajk is talking about), since the files might be physically stored on another server, anyway. all we really care about is if the file_path is set in {project_release_nodes}, which determines what kind of form elements get built by project_release.module.
Comment #6
dwwfrom IRC: killes: dww: looks ok
committed to HEAD and DRUPAL-4-7--2, and installed on d.o.
hopefully this should prevent any more nightmares like http://drupal.org/node/129040
Comment #7
(not verified) commented