Fix pift_cron_autofollowup_logic

We could

A) Update the status if the file is displayed. The logic would be the most straightforward of the options.

B) Update the status if the file is attached to the most recent comment with added files. The logic might not be fun; although the node changes API could help. This would most-closely extend the current logic.

I'm not sure what makes sense to more people in the issue queue. I am okay with either.

I think (a) is enough: mark the whole issue as needs work when one of its displayed patch failed testing.

Hm.

The idea is that you can do this:

File1: test-only.patch
File2: test-and-fix.patch
File3: interdiff.txt

This used to work more or less implicitly on 6.x because it only updated the issue status if no other patches were being processed, so the last one often also came back last and the test-only did not set it to needs work.

I guess this is an attempt to support this explicitly?

What about applying the "should-this-file-be-sent-to-testbot" function/logic on the filenames, and basically check if it's the latest file that is named so that it's tested?

Looks correct to me on a visual review. variable names could some improvements.

What you have there aren't really files, they are file field items. So maybe "foreach ($reversed_file_items as $file_item)"

And using $file_items = field_get_items($node, 'field_issue_files') would allow you to clean up that language stuff a bit, you don't have to mess with 'und' then. field_set_items() unfortunately never made it into core, so you still have to use the constant there.

While noticing an array_reverse() in this patch...

Part of the issue might also be this observation:

When attaching multiple files, the UI makes it appear as if you'd add them in the intended order, but:

After submitting (saving), the files that you attached are actually attached in the reversed order.

Once you notice, next time you try, you can actually take the extra experimental course of clicking the "Show row weights" link that happens to be there. And indeed, after disabling the tableDrag JavaScript:

When attaching new files, the weight of a new file has a "negated" weight compared to all other/existing files.

In turn, first == last, and first != first.

Yeah, I'm just not sure whether the tableDrag JS was also adjusted accordingly — whenever I'm trying to ensure that the .patch appears first (as opposed to the interdiff), I get an unexpected result.

But I merely wanted to note that ordering aspect in case it's relevant. Looks like it's not and the UX issue I'm talking about is a different issue. Thanks! :)

See #2098099: The issue queue *must* make it easier to upload/review patches and #2102365: Improve file list layout on node edit form for background on file reversal.