Limit number of files displayed on issue pages to files on last 'x' comments

Can I propose an alternative?

The motivation behind the checkboxes, and not just displaying the 'last three patches' by default, is that issues can go down the path of one potential solution, decide it's a dead end, and go back to a much earlier patch to pursue a different alternative. What we want to display is the most 'relevant' patch, not just the most 'recent'.

I still believe that the proposed workflow (i.e. clear the 'display' checkbox on the last patch when you upload a new one which obsoletes it) is not nearly as disruptive as it's been made out to be. The reason folks are pushing against it is the anticipated pain introduced by long tables of files, given that we have current issues with dozens of patches ... and endless scrolling as a result.

We could potentially solve the 'long table' problem while still keeping the proposed workflow, by hiding all but the last 3-5 patches as part of the upgrade / migration ... but then encouraging the 'hide previous during upload' workflow, so that we can still support display of the most 'relevant' patch, regardless of whether it was posted early or late within the comment thread.

One minor enhancement which would also improve the 'hide during upload' workflow is a 'check all / clear all' checkbox for the display column.

I guess my problem is the proposed workflow makes no logical sense to me, since it's optimizing for a 0.0005% case where an issue gets so long and complicated and/or so heated and angry that completely divergent approaches happen in the same place, and the more valid one is earlier in the stream. The vast, vast majority of issues are not like that. If divergent approaches are tried and one fails, the simple solution is re-upload the old patch, which people do today, since the "most recent attachment" link is pretty much everyone's go-to nav as soon as they hit an issue page.

Worse, the act of manually unchecking the visibility of files that are no longer relevant is not behaviour I've encountered in any other issue tracker I've used: bugzilla, github, trac, etc. We are doing a tremendous push in Drupal 8 core right now to "get off the island" and embrace "proudly found elsewhere," it doesn't make sense for our tools to be pushing us more and more into "Drupalisms."

And finally, the problem with the entire idea of "someone needs to manually check/uncheck the visibility of uploaded files" is that either a) people won't because they miss that they need to do it, and the file listing will be wildly inconsistent between issues or b) people *will* and will use it in a "weaponized" way to hide work from people they disagree with. :(

So basically, I'd really prefer to stop trying so hard to get this workflow to work, and instead optimize for the 99.9995% case with dumb, automated listings that behave predictably across issues and do what people want in the vast majority of cases.

Jthorson and I talked about this more on IRC and think we agreed that a combination of allowing for manual field *ordering* (which should be core functionality in multivalue fields) and 'display last 3' from the field order would be a good middle road to pursue. Although, that still leaves the problem where people taking screenshots of patches while testing will push the patches off the list and the most important thing to resolving issues is that you can easily get to the patches that resolve them!

So please, please don't make this hard. :) I want people to be excited about d.o D7 launching, not infuriated that they can no longer do their jobs.

After an IRC discussion with Angie, #1 is probably overstating the extent of the 'relevant' versus 'recent' issue ... but I still feel that having to re-upload an issue to get it back into the 'displayed' files list if it's spammed out of the display would be settling for a non-optimal solution.

Another option to consider would be to display the 'last 3 patches' as determined by the file field order, instead of the comment thread order. Each new patch naturally goes to the bottom of the file field order, and would thus appear in the 'last 3' when uploaded ... but, it would be possible to revive an earlier patch by showing the hidden files and tabledragging that particular patch to the top of the field list (top, since the files would be displayed in reverse order relative to the 'field order').

1) That was the "implementation" description. The "usage" description is that we display recent files based on how they are sorted in the field widget. If you want to revive an earlier patch, drag it to the top of the widget.

2) Any approach we come up with can be weaponized. With the 'last 3' approach, if someone proposes an alternative approach to solving an issue, and I don't agree with it, I can bury it by posting three patches (or one patch followed by two typo/whitespace corrections). We self-police within the community, and will continue to do so ... I prefer to not discount any particular proposal based on the risk of it's potential misuse.

Angie and I discussed this at length last night (to a consensus), and there were a few use cases which don't quite fit in with the 'last 3 files' approach:

1. Issues that dead-end and reset back to a much earlier patch
- eg: https://drupal.org/node/1289336, comment 70 suggests we need to go back to comment 20 and work from there)
- We agreed I was probably overweighting the significance of this scenario, and it's a slim edge case.

2. Issues where people are building towards a screenshot or mockup
- We need a way to not bury the screenshot, and constantly re-uploading it every 3 comments in order to get it back in the display is inefficient.
- This is not a primary use case for the issue queue, but it's far from an extreme edge case.

3. Non-patch issues, discussing potential designs/alternatives
- The screenshots are the important content in these issues; only displaying 'patch' files is optimizing to one use case at the detriment of all others.
- The same goes for 'community' projects, where there will be attachments, but they won't neccesarily be patch-based.
- Again, not primary function, but also not an extreme edge case.

I should put on my flak-resistant jumpsuit before suggesting this with this particular wording, but while we are optimizing the developer-centric workflow, let's make sure the end result is still workable for the variety of other issue queue use cases we leverage on drupal.org.

For the purpose of the contrib module, I've added a 'Number of items to display' setting to the field formatter for now. This just works on a straight 'file count' basis, as the contrib module doesn't include comment IDs by default (comment ID info is added by nodechanges through an alter hook).

My intended next steps for now are:
i) Add a 'show all/hide' toggle to the file table, which will use javascript to toggle display of the hidden files which exceed the configured count.
ii) Create a drupalorg patch which configures the formatter to only show 'x' items, which will get us about 75% of the way to the intended functionality
iii) Sort out how to handle the 'only show patches' and/or 'restrict by # of comments' logic ... not sure if this will end up in extended_file_field or drupalorg.

I think we don't need the "only show patches" logic anymore, as long as it's a) the last 3 comments with all of their file attachments, not the last 3 file attachments in total (which I believe is what we discussed), and b) there's JS to easily show the rest of the collapsed table easily if the file you're looking for isn't right there. (we did identify one "edge case" issue where there were enough comments w/ screenshots to hide the patch file, but this is definitely not the norm)

The "last 3 patches" logic is not ideal, because a) it will only apply to d.o (we're stuck in the dark ages still, most others use real branches :P) b) it totally falls apart for issues that are completely graphic-focused, like "design a new logo for X."

Agreed. The issue is that the extended_file_field contrib module alone is not comment-aware ... the comment ids are added via a hook_alter() in the nodechanges module. We'll either need the nodechanges hook to add the formatter setting and logic for 'last x comments', or put the logic in a third location (such as drupalorg module).

I've got it set up to show just the last 5 files for the moment (after the next full migration runs). I'll come back and tackle the logic for 'last 3 comments' in a bit, but am going to shift gears and tackle the edit page first. My motivation is that, even though it's not the complete end state we're going for, the 'view issue' experience should now be at least 'bearable' for end users given the current codebase, while the edit experience still needs plenty of love.

Just a thought that the 'last 5 files' functionality may be enough for launch, and the 'last 3 comments' extension to this could be repositioned as a non-blocker / post-launch enhancement.

Works for me.

As per #9, the base 'limit files' ability is now in extended file field as of http://drupalcode.org/project/extended_file_field.git/commit/fe476539739..., and the javascript toggle as of http://drupalcode.org/project/extended_file_field.git/commit/9540dafd784....

Remaining is the ability to limit this to all attachments on the last 'x' comments instead of simply the last 'x' files.

Removing D7 drupal.org tag, and re-classifying this last step as a post-launch followup.

Updated issue summary

Updated issue summary.

Updating issue summary

This seems like more of a UX issue than D7 followup.

I discussed this with jthorson and the best way to move forward seems to be webchick's a) in #7. Although there are also cons to this approach, its the one with the least impact on the flow of the discussion.

TBH I'm rather surprised this issue is still open. This dates from back in the day when we were displaying all files on issue view, and then expecting a human to manually uncheck dozens of boxes to make the list sensible. Nowadays, the table on view is already limited to the last few comments files. The only thing we're lacking is a way to see all old files in that table (that'd be #7b), but you can also get to them from the files fieldset down below, so I think we can just close this, personally.

EDIT: Oops, I guess it's last 5 files. Still. I haven't seen anyone complaining about those tables since launch, and though I find the "display file" checkbox to be an utterly useless feature, there are "issue pruners" out there who like it and make use of it.

I'd be fine with that ... the move from x files to x comments is not trivial, and we can make any further changes past of new issues, or larger redesign initiatives.

Given webchick's comment, looks like this is okay.