Closed (fixed)
Project:
Update Status
Version:
5.x-2.x-dev
Component:
Miscellaneous
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
7 Mar 2007 at 23:28 UTC
Updated:
4 Jul 2007 at 01:16 UTC
Jump to comment: Most recent file
Comments
Comment #1
dwwit would require much more than support from this module:
1) release nodes would need to have a flag to indicate they include a security fix
2) contrib maintainers would have to set this flag accordingly
3) the XML-RPC interface on drupal.org that serves the info used by this module would have to be changed to return this data
then...
4) this module would have to display the data in some useful way in the UI.
this would all be good, and in fact, has been planned for months, but none of it is done yet. in fact, there aren't even issues posted for #1 and #3, yet. so, for now, this particular request must be postponed until these other things are resolved.
thanks,
-derek
Comment #2
dwwbump: i just submitted http://drupal.org/node/136172 as an issue about changing the XML-RPC protocol to be able to support this sort of thing.
Comment #3
dwwsee http://drupal.org/node/142344 -- we've now got a "Security update" term we can apply to release nodes.
and, progress continues at full steam for http://drupal.org/node/136172
so, this issue is active again... i'm also bumping to "critical", since we need a working prototype of this functionality ASAP so we can fold it into core in time for the D6 code freeze.
Comment #4
dwwthis is nearly done in the 5.x-2.* series...
Comment #5
dwwminor visual problems with the current version. see screenshot. patch forthcoming.
Comment #6
dwwscreenshot of proposed fix.
Comment #7
dwwpatch that accomplishes the previous screenshot
Comment #8
dwwcommitted slightly modified version to HEAD. webchick pointed out that the underline made it seem like a link, which is a no-no. it would be slick if we could have that be a link to the right SA, but that's actually a huge can of worms that would require even more work on the server side.
setting this back to active so that we can work out the edge cases with releases marked as Security updates that have extra in the version number (e.g. project_issue 5.x-0.2-beta).
Comment #9
dwwafter discussion in IRC, we decided it's somewhat confusing on the case where a security update happened but another (non-security) release is already available. audio.module is a good example. 5.x-0.3 was a security update, but 5.x-1.0 is now out. before, if you were running 5.x-0.1 and ran update_status, it'd correctly tell you that you need to upgrade b/c of a security update, and it would correctly recommend you install 5.x-1.0, but it wouldn't give you any link to 5.x-0.3 to see what the security problem was. attached patch fixes this. it's somewhat simplistic, in that it always lists a "Security update:" row in the table, even if it's the same info as the "Recommended version:" row. however, we think that might be a feature, not a bug, since it helps drive home the point there's a security update. ;) screenshot coming next.
Comment #10
dwwscreenshot of the above. doesn't show the case where the security update == the recommended version, but i think you can imagine that.
also, this is just a list, so if you're running something really old and there have been N security updates, each one will be listed in the table for that project. i can't find any real examples of that to demo yet, though i guess i could put some bogus data on s.d.o and point my install at that if we really wanted to test it. ;)
Comment #11
dwwnow, with the "Security update:" label wrapped in a span with the same class as the "Security update required!" stuff.
Comment #12
dwwi like #10 better than #11: if the recommended version is newer than the security update, we really want them to upgrade to the recommended version, so extra visual attention to the security update release might be counter-productive. so, i committed #9 to HEAD.
Comment #13
dwwbump for clarity: the only reason this issue is still active is because of the edge case where the latest release for a given major version we're tracking is both a security update and a beta, as is currently the case for project.module and project_issue.module. once we handle that, we're done here.
Comment #14
dwwmy patch at http://drupal.org/node/149918#comment-261116 solves this, too.
Comment #15
dwwYay, this is working fully, now that http://drupal.org/node/149918 is committed.
However, over at http://drupal.org/node/149918#comment-261964 merlin rightly pointed out that the UI looks a little wonky for this. In IRC, he suggested just replacing the "Update available" text with the "Security update required!" part. Sounds good to me. I'll work on a patch now.
Comment #16
dwwComment #17
dwwscreenshot of the latest. i know we talked about this before, but i'm having 2nd thoughts about including both "Recommended version" and "Security update" if they're both pointing to the same thing. If there are multiple security updates, I can see it, but what's in this screenshot is a little weird, IMHO.
Comment #18
merlinofchaos commentedThis patch changes the text from a div to a span and removes padding and floating that is no longer necessary.
Comment #19
dwwBuilding on merlin's fixes to my previous patch:
1) Don't bold the "Security update:" part, allow the red color to visually distinguish it. We still bold the "Security update required!" part in the status area. But, excessive use of bold makes this look cluttered, and makes it harder to use bold where we might need it.
2) If there's only 1 security update, and it's the same version as the recommended version, don't print it twice. Just print the the "Security update:" line, not the "Recommended version:" one.
Comment #20
dwwmerlin and i discussed this more in IRC. we agree we *could* use that bold in some cases, just not all. so, we'll tackle the use of bold over at http://drupal.org/node/149079. meanwhile, committed #19 to HEAD.
Comment #21
(not verified) commented