Closed (works as designed)
Project:
Project issue tracking
Version:
7.x-2.x-dev
Component:
Issues
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
8 Oct 2005 at 21:55 UTC
Updated:
19 Nov 2013 at 23:41 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
babbage commentedThought I'd clean up some old issues in this queue—hope that is OK.
While not implementing the exact functionality described here, over three years ago, the current "Jump to: Most recent attachment" seems to address the usability issue identified here. Going to mark this as fixed—probably a duplicate of other issues that actually led to the link but not that easy to find.
Comment #2
babbage commentedMove to correct queue.
Comment #4
klonosReopening this one...
I am attaching a 'fresh' screenshot to update the one posted in #0 + listing features and ideas that I think we should 'borrow' from the way bugzilla does it:
- Group posted attachments together and place them on top of the page, near the issue's summary (#569552: Provide a mechanism for issue meta discussions)
- Distinguish attachments. For example based on color (if it is a patch, so we know its status), text stroke (obsolete by another attachment) etc.
- Hide obsolete attachments by default (so that only the latest patch is shown), but provide links to show all or obsolete ones only.
Comment #5
klonos...and here's a second screenshot that shows how the upload is handled:
- uploader has the option to select the type of the attachment (patch, screenshot etc.)
- previous versions of the patch can be marked as obsolete.
Comment #6
klonosAny thoughts? Does anyone like my proposal? No? Do you think it would be a useful feature? Can it be implemented relatively easily? Anyone??
Comment #7
pillarsdotnet commentedMaybe it would be better/simpler to make the default view collapse to the latest patch/attachment plus the latest ten comments, with a "Read more" link to show the rest of the context.
Comment #8
klonosThat would be really great Bob, but only if these 10 (or whatever) comments were not 'subscribe' and/or '+1' messages. I like the summarized + 'read more...' link idea, but how do we filter useful comments? You know most people will not even look at the 'read more' link.
Anyways, my whole idea was (to a certain point) based on the same initial idea behind #1036132: Provide a mechanism for issue summaries but for comments. That issue has taken another way though -using the Flag module-. Perhaps the same module could be used to flag attachments. I don't know.
Comment #9
pillarsdotnet commentedWell, if there were some way to +1/subscribe without leaving a comment, that would solve the problem, wouldn't it?
Comment #10
klonosYep, it would, but my point here:
...was that some comments are simply not worth being displayed (and I mean this in a nice way as in: 'They don't directly help the issue progress'). I was just using the extreme, most-hated case as an example. Consider the few dozens of 'How do I apply the patch in post #x?' messages or 'Dev version? I see no dev version in the downloads section?' + the few dozens 'Here's how/where' replies as another example if you wish. These will never go away.
I would love to see -for example- the fruits of #1036132: Provide a mechanism for issue summaries being shown and the rest of the messages filtered out in a 'read more...' link. But that's a thing to be addressed in that issue I guess. This one is about attachments.
If you take a look at the screenie attached in #5, you'll notice how attachments can be (optionally) marked as being obsolete by new ones. If this 'mechanism' is implemented for attachments (especially patches) in d.o, we'll also have a "patches/attachment summary" besides an issue summary. This summary would include only the latest patches/files and have a 'more...' or 'older versions...' link like issue summaries. Now, if this piece of info is gathered all in one place and is somehow placed near the issue summary(ies) one will be able to actually speed-read through an issue with ease.
PS: See? ...this talk made me come up with an even better title for this issue. Let's hope it makes it more 'attractive' too ;)
Comment #11
klonosHere's a screenshot that shows how obsolete files are hidden from view by default, but can still be toggled in view if one desires to see them:
Comment #12
dwwThis is the direction we're moving in the D7 port of project_issue. See #1545922: [META] Issue page redesign for more.
Comment #13
klonosAFAICT this feature is now implemented in 7.x and also deployed in d.o after its recent upgrade to D7. Is there anything else to be done here? Should we move this to 7.x or do we intend to backport the feature to 6.x as well?
Comment #14
dwwNot going to backport this. Closing since this is how the D7 port works.
Thanks,
-Derek
Comment #15
klonosFair enough. Thanx.