Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
...as per issue title.
If a file was attached to an issue along with the original report (for example the person that reported it also attached a screenshot), there is no way to remove it or replace it or to add a new one. A screenshot might be ok to be left there as one updates the summary, but when it comes to attached patches these tent to get obsoleted by new ones and thus old ones need to be removed/hidden.
Proposed resolution
- Allow attached files to be hidden (as obsolete).
- Allow obsolete files to be toggled into view.
- Allow new files to be uploaded and added.
- Allow newly added files to mark/flag previous ones as obsolete.
Here's a couple of screenshots from the related issue #33475: Attachment summary: Issue attachments should be grouped together and placed on top of the page - near the issue summary that demonstrate how this is done in bugzilla (first one shows the edit/upload part, second shows the way it is presented to users):
Remaining tasks
...
User interface changes
Users will see extra controls in the issue summary that will allow them to do the tasks described in the "Proposed resolution" section above.
API changes
???
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | obsolete_files.png | 24.43 KB | klonos |
Comments
Comment #0.0
klonos...conforming to the issue summaries standard.
Comment #1
klonos...anybody?
Comment #2
dwwIt's already bad enough how summaries are implemented that anyone can rewrite the history of my original post. We're not going to let you delete/replace my attachments, too. If you have a better patch/screenshot/whatever, include a link to it in the updated summary.
Comment #2.0
klonos...added reference to the bugzilla screenshot.
Comment #3
klonosWhow! ...take it easy Derek.
Please take an extra second to read through my proposal. Deleting attachments is not the only thing I propose. Actually I never mention the word "delete" at all. Perhaps I did not make it clear, but I wasn't suggesting deleting them from the filesystem. When I say "remove", I mean to be able to mark patches in a way that denotes that they are known to be causing issues. Perhaps marked with strike-trough or removed from end user visibility (still able to toggle that though). Please take a second look at the old screenshot in the issue summary + the new one I attached as well to see what I mean.
The other issue I link to will take care of moving all attached files in a more prominent place so that users don't have to dig through the whole issue to find them. This one here will take care of being able to "flag" attachments in a useful way in order for people to warn and be warned of current file (mainly patches) status.
Comment #3.0
klonosMade it clear that files marked as obsolete should not be deleted from the filesystem but rather hidden from view (toggle ability). Added another screenshot and converted old one to and img tag.
Comment #4
klonos...hope the issue title change makes it a bit more clear.
Perhaps I need to update the summary too. ...Done ;)Comment #5
dwwOkay, yes, that makes more sense. In fact, this is now the direction I'm arguing we should go during the D7 port. See #1545922: [META] Issue page redesign for more...
Comment #6
klonosIt was mentioned in #1628044: Implement magic for the table of attachments on issues that:
I agree. And that's precisely why we'd need to make sure that there is no deletion whatsoever (with the exception of admin/spam deletions). We need to figure a way to implement this notion of "obsolete" files that are never deleted - only hidden from normal view.
In order to avoid the aforementioned situation where a user would not want their file to be marked as obsolete, I propose this workflow:
1. a user uploads a file and at the same time marks an older file as obsolete.
2. if the owner of the old file happens to be the same user as the newly uploaded file, then the old file does get flagged as "obsolete by ..."
3. if the owners of the old and new files are different users, then the owner of the old file gets notified and is prompted for confirmation. If they accept, the old file is marked as obsolete. If not, both the old and new files are kept.
4. if the owner of the old file does not reply with a yes or no (old inactive users), then after a certain period the old file is automatically obsoleted in favor of the newer.
5. if we have more than one files in a non-obsolete status competing with each other (with pending obsoletion requests), then the one that is committed by the maintainer is the one that obsoletes the rest.
Alternatively, we could #1851380: Allow voting on uploaded files.
Comment #7
dwwThanks for your feedback, klonos. However, this sounds a) complicated and b) a ton of work to implement. The people actively coding the d.o Project* upgrade (at this point, that's mostly myself, drumm and bdragon) definitely do not have time to write a system as complicated as you're proposing with authorship comparison, notifications, approvals, timeouts, etc. While I'm sure someone will come along and explain how with only 20 hours of clicking around and 1000 lines of custom triggers and actions, you could use Rules for this, that doesn't really help us, either. ;)
At this point, the plan discussed at #1628044: Implement magic for the table of attachments on issues and the related issues is the only viable one I see (although the issue summaries aren't perfectly updated in all of those issues, yet). You quote me from that thread in your comment, but didn't seem to read the rest of the thread where I answer myself. ;) Instead of a fully-automated system with notifications and approvals, I'm proposing that we re-expose the "show/hide" checkbox on file uploads, and let crowd-sourcing (and an always-visible history of changes) "solve" the problem for now. Anyone can hide files, but you see they did that with the auto-generated comment which is created whenever someone updates an issue (for any reason). If the owner of the now-hidden file disagrees, they don't have to get separately notified (since if they care, they're presumably already following the issue and will be notified that someone updated the issue, anyway), and they don't have to separately approve/deny (since if they disagree, they can just edit the issue and show their file again). Just like people can get in pushing matches over the status of an issue, they can similarly get in a fight about the visibility of a file. Progress! ;) But, the points are: a) you will be able to hide obsolete files and b) no one can ever delete files (except perhaps spam fighters -- ugh).
Anyway, we desperately need implementable plans (or better yet, working implementations) not wish-list workflows that might be great if we had unlimited development resources (which we don't). If you want to actually start coding the plan I outline in #1628044, please do. If you want to help move it along in other ways, please point out any possible problems with *that* plan and/or update the issue summaries to reflect the (full) plan in those issues.
At this point, I'm tempted to mark this issue duplicate (even though it's older, sorry) just because basic functionality outlined here is already addressed in those other issues (which are what's going to be implemented and deployed unless there are compelling and fatal flaws in them).
Thanks,
-Derek
Comment #8
klonosYes, I understand the point you are trying to make Derek. Honestly though, you shouldn't have to go through all the trouble and type all this in order to explain - a simple "we don't have the time right now" would perfectly suffice because I realize the complexity of what I am proposing. I follow quite some issues and also realize that there are time constrains + I am aware that we are battling against Dec, 1st core feature freeze + the fact that we are working for a d.o D7 upgrade + other things I might not be aware of. I guess what I'm trying to say is thanx for even taking the time to read my post and I really appreciate the time you took to reply, but please leave this issue open till we have an actual solution. Then we can compare that to my proposal here and see how/if we can improve things. Thanx once again.
Comment #9
klonosClosely related: #1956166: Auto-generate interdiffs between patch files (from patches uploaded previously).
Comment #10
dwwGiven that Extended File Field now exists and handles hidden files properly, calling this fixed.
See the Table of file attachments section of #1545922: [META] Issue page redesign for more.
Comment #11.0
(not verified) CreditAttribution: commented...clarified what the two screenshots depict.
Comment #12
klonos...I'm reopening this one - not as part of the d.o D7 upgrade task itself, but rather as an improvement and in order to implement the original idea that is explained in the issue summary. I understand that we might not have the resources/time/energy to implement this right now though. So, postponed.
Comment #13
dwwAs far as I understand this issue, the functionality is now deployed. That's what's currently called "filtered files" and what's toggled via the display checkbox when you edit the table of files on an issue. What more is needed here and why?
Thanks,
-Derek
Comment #14
klonos...I totally missed that. Sorry :/
I guess the "Display" label is either too vague or the workflow a bit different than what I'd personally expect, but yeah that gets the job done so it's good enough for me - it might just need a bit of getting used to it. Let's see if we get complaints/questions from others.