Closed (fixed)
Project:
Project
Version:
5.x-1.x-dev
Component:
Releases
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
9 Jan 2007 at 10:25 UTC
Updated:
24 Jan 2007 at 09:17 UTC
Set proity to minor as I don't know how important this is.
My module: path_image
Last night I did some fixes to my module, well, I thought I did, but I screwed it up. After doing some stuff, I created a release 4-7--1-4 and moved on. My screw-up was reported to me on an issue.
No problem, I fixed it up and then did a new release, 4-7--1-5. All's well, within 5 mins the packaging script did it's work and I'm happy.
However, 4-7--1-4 was not a little broken, it was terminally broken. Now, I know most people will get the latest release (1.5) but I wanted to make sure no one downloaded 1.4 so I went to that release and edited it. All I did was add <strong>This release is broken, do not use</strong> to the body text.
However, after I saved it, that release disappears from the "View all releases" page. Not that I'm bothered, I didn't want it to be downloaded anyhow. But I can't help thinking, "what would happen if I edited the body text of my current 1.5 release, would it also disappear?". I'm not about to edit it and find out ;)
Comments
Comment #1
AjK commentedfwiw, 4-7--1-4 also has disappeared from the "Version" select field in the issue tracker. So I guess this screwed up more than I thought. The issue that cause me to create 1.5 in the first place (http://drupal.org/node/107944) now shows the bug against 1.5 (it appeared to be changed to 1.5 by the reporter saying "thanks" as since 1.4 wasn't in the select list it defaulted to 1.5). So that issue report is now filed against 1.5 which is incorrect and I can't change it back again.
Comment #2
dwwa) the node was just unpublished. it's back now: http://drupal.org/node/107825
b) the thing about the version number not appearing in the choice of options is a separate issue. it's currently like that by design, but i don't like that design. ;) see http://drupal.org/node/97145
c) yes, it's probably a bug that it was unpublished when you edited it. ;) i have a suspicion, so i'll look into it and see if i can find it.
Comment #3
dwwugh. :( this is what happens when so many bits of functionality depend on permissions -- makes it hard to test all the cases.
IMHO, this is a bug in core. however, it's behaved this way for ages, so i suspect i'll have a hard time convincing people it's a bug. here's the story:
a) i've configured release nodes to *default* to be unpublished, so when they're first created, they're not published...
b) the packaging scripts publish release nodes once the tarball exists
c) when the author of the node tries to edit, if they don't have 'administer nodes' permission, their node form doesn't include any of the workflow options
d) when they submit, since the workflow options aren't in the form, core defaults to resetting all options to the defaults, instead of just leaving them alone.
so, if you were a content admin, at step (c) the options would just be in the form, and when you saved, it would have remain published. step (d) seems like a core bug.
to work-around the core bug, i could add special code to project_release.module to unpublish new release nodes by default, but set the core default workflow setting to published, so that mere mortals could edit their own release nodes without unpublishing them. *sigh*
i'll followup here if/when i either give up on fixing the core bug, or have an issue about it where you can track progress. we'll also have to consider if it's worth this (total hack, IMHO) work-around described above...
Comment #4
dwwcalebg was kind enough to find this for me in IRC: http://drupal.org/node/38451 ;)
there's the core issue. i'm going to go weigh in there now...
Comment #5
AjK commentedI understand the workflow/problem as you describe it.
Just to clarify, I'm a D.O "doc admin" so is that why I have the edit tab? Do "mere mortals" have an edit tab on project release nodes? If they don't then I don't see this as a big issue. We people with doc admin should just "not edit release nodes". Imho I was surprised to find I could edit a release node at all. I personally think once a release comes into being it's fixed, non-changing, static, etc so I would be happy for the module to disable the edit tab completely (except for uid==1, there's always a special case somewhere) if it can.
Comment #6
dwwa) because it's your release node, and you can usually edit your own content
b) you should be able to edit for exactly the use case you described originally: you want to update the notes about a release to say "this is broken, use 1.5 instead" or whatever. what if you're lazy at first, but later decide to provide detailed release notes using my handy script (as described at http://drupal.org/node/94151)?
if you notice, your abilities to actually change anything of substance on the release nodes when you edit them is highly restricted. basically, unless you have 'adminster projects' perms, you can't really edit much of anything except the body/description. changing the CVS tag, the version number, etc, etc -- i absolutely agree -- you shouldn't normally be able to edit that. but, fixing typos, expanding, or otherwise keeping accurate the release notes... that's definitely a good feature to keep.
Comment #7
dwwyay, my patch for http://drupal.org/node/38451 was just committed to core (thanks, Steven!). ;) so, i updated the copy of core running on d.o and now this problem is fixed. yee haw!!
-derek
Comment #8
(not verified) commented