Provide an explicit relationship between patches and comments about patches

Indeed, this came up in our in-person discussions about how to handle files attached to issues as part of #1545922: [META] Issue page redesign. A few ideas that came up:

a) provide some funky syntax (like the issue reference like #123456: Drupal website oupedia.com with imported joomla template stuff) that lets a given comment refer to a specific file.

b) provide a field on issue comments that references a specific file. Maybe the table of files would have a "respond" link that jumps you to the comment form with that field already specified, but you could also just set it to a specific file when commenting.

... ?

Moving to the right queue...

Wacky idea, but if we're going to have multiple streams of things anyway, what about attaching comments to the file entities?

We actually discussed this idea a bit during the Portland sprint, and it's a good idea because it would allow notes about a specific patch to be shown as 'child comments' of the original attached patch rather than 22 rows down in the discussion stream, but the UI for offering participants the ability to A) update the issue, B) comment about the issue as a whole, or C) add a comment below a comment which talks about the attached patch which is really attached to the issue and not the comment...

It was too hard to figure out. :) We just need to get everything fieldable that we can during this D7 upgrade, and worry about nested field interactions during Phase Next.

I just posted #1545922-66: [META] Issue page redesign that might help solve this problem.

This is basically blocking #1628044: Implement magic for the table of attachments on issues so I'm bumping the priority.

This is a hard problem. We need a place to remember what comment was auto-generated when a given file was attached to an issue node. Perhaps we can just search through the comments on the issue and inspect the node changes data, looking for a matching fid, but that seems a bit ugly. There was talk of having a revision ID reference in the auto-generated comment, but I don't think it's easy to figure out what node revision resulted in a given file being attached to the issue. Maybe we could just explicitly store the comment ID that was auto-generated as part of saving the node revision, and have our own mapping table of revision ID, file ID and comment ID.

UI-wise, it's further complicated by the fact that a single node revision (which results in a single comment) can attach multiple files. So from the UX of issue participants, it's not enough to just refer to "file #3" if comment #3 had 4 files attached. Maybe we want a sequence ID for files attached to an issue along the lines of #1632492: Figure out and port project_issue comment numbering functionality to D7?

I'm going to be pessimistic and say this is 4 solid days of work to come up with a workable plan, implement it, test, etc.

What if we kept the file reference field on comments, so that a patch was referred to by both the node and the comment? Then it's just an EFQ to find which comment points to the patch.

See project_issue_add_file_cids() in the patch at http://drupal.org/node/1628044#comment-6803128 for one potential approach.

Edit: There's no need for a file reference on the comment itself, as there is already a reference to the file in $comment->field_issue_changes which can be EFQ'd against.

We now have project_issue_get_file_cids($node, $field_name) committed. What is needed to close out this issue?

Instead of thinking about the code, think about the people trying to contribute via the issue queues. These days, people refer to "patch #3" by which they mean "patch uploaded to comment #3". We now have the table of files that includes the comment each file was attached at. So, cool. Maybe that's enough.

However, the intention of this issue was to have a way when people were contributing to an issue to explicitly tie their changes/comments to a particular file. Since #1628044: Implement magic for the table of attachments on issues is done, I think the D7 port is now functionally equivalent to D6 in this respect, so I think we can consider this issue as a post-launch feature, if we in fact need a more elaborate mechanism.