Append node ID to project issue file attachments [#88911]

It's really helpful to know the context of a patch or file, so you can go back to the issue to look and see how a patch came to be and what was said about it.

One easy way to do this would be to automatically alter the file name from:

big-project-thingy.patch

to:

big-project-thing-13234.patch

where 13234 is the node ID of the issue to which it is attached.

If I uploaded another big-project-thingy.patch, it would be called:

big-project-thing-13234_0.patch

and so on.

Obviously, not a huge priority; releases as nodes stuff takes precedence, so marking as postponed. It would be nice though. :)

Comments

Comment #1

hunmonk CreditAttribution: hunmonk commented 29 August 2007 at 03:59

Project:	Project issue tracking	» Comment Upload
Version:	4.7.x-1.x-dev	» 5.x-1.x-dev
Component:	Issues	» Code
Status:	Postponed	» Active

given that issue followups will soon be real comments, and this will be our method of attaching files, moving this over.

Comment #2

hunmonk CreditAttribution: hunmonk commented 29 August 2007 at 04:01

Title:

Append node ID to file attachments

» Append node ID to project issue file attachments

Comment #3

mr.baileys

Dutch

🇧🇪 (Ghent)

CreditAttribution: mr.baileys commented 2 February 2009 at 09:28

I'm new to Drupal, so I don't know how the issue queue used to work before the entire IFAC thingy, but I'm thinking that this is no longer an issue since context for a patch/file is now provided by the comment it is attached to, right? Or am I missing something?

Comment #4

webchick

she/they

English

Vancouver 🇨🇦

CreditAttribution: webchick commented 5 February 2009 at 05:35

Summary of bike-shed in #drupal:

[project-short-name]-[issue node id]-[issue reply number]-[name of patch].patch

like:

comment_upload-88911-4-webchick-loves-you.patch

;)

Comment #5

webchick

she/they

English

Vancouver 🇨🇦

CreditAttribution: webchick commented 5 February 2009 at 05:36

And @mr.baileys: It's still an issue if you want to have a sensible management strategy for patches, ala http://www.lullabot.com/articles/strategies_for_patch_management. Otherwise you end up with patches like t_0.patch, mw_58.patch, etc. Auto-appending this data to patch filenames would make it much more obvious where they came from, when, and why.

Comment #6

dww

we/he/they

CreditAttribution: dww commented 18 April 2009 at 03:26

Version:

5.x-1.x-dev

» 6.x-1.x-dev

netaustin accidentally committed code for this to comment_upload.module when trying to fix #379470: Change in the issue description is discarded after clicking on the attach button. However, that bug is still broken, so that code is not being deployed yet. I'm tempted to remove those parts of the revision, since we should really be handling this feature here via a separate (and reviewed) patch, instead of doing multiple things in the same commit.

Also, I'm a little worried about how the accidental code is written -- on very brief inspection, it appears to always prepend the nid and comment id. I'm in the habit of posting patches with:

[nid]-[comment_id].[description].[version].patch

(version is optional, but for stuff like "d6" or "d5" or "head", etc).

I do this both so that folks downloading the patches know what it is, but also so my own local copies are all well-named and sane so I know what's what. It'd be annoying if d.o renamed my patches to

[nid]-[comment_id]-[nid]-[comment_id]...

all the time... Probably the code should check to make sure the filename doesn't already include the data it's trying to prepend or something.