JILS-30: Attachments functionality broken

Within the Issue view page, the link to an attachment is generated by

qs2sef("attachment={$attachment->ID}&fname={$attachment->FILENAME}&projid={$issue->pkey}-{$issue->issuenum}");

(https://github.com/bentasker/Jira-Issue-Listing/blob/4304af6e6382f2ff6d21cd216f76a5bc69e62d03/issue_page.php#L415)

Nothing in qs2sef (https://github.com/bentasker/Jira-Issue-Listing/blob/4304af6e6382f2ff6d21cd216f76a5bc69e62d03/utils.class.php#L407) looks too far out.

It looks like parseSEF (https://github.com/bentasker/Jira-Issue-Listing/blob/4304af6e6382f2ff6d21cd216f76a5bc69e62d03/utils.class.php#L470) is doing it's job OK and getting us into the attachments processing.

huh.... that's odd...

Looking in /var/atlassian/application-data/jira/data/attachments/ it seems that JIRA uses a project's original key, rather than the current one. The project I noticed this on originally had a different key.

So, assuming the following

Project Key: EXAMPLE
Original Project Key: ANEXAMPLE

Attachments for any issues under that project won't be in /var/atlassian/application-data/jira/data/attachments/EXAMPLE but in /var/atlassian/application-data/jira/data/attachments/ANEXAMPLE (to be clear, even if the issues were created after the project key changed).

So, if the attachment file we're looking for doesn't exist, we should probably connect to the database and see whether ORIGINALKEY exists. Either that, or use it when generating the initial link.

The problem with doing the latter is if it was changed for a reason (e.g. was an expletive) then URL paths will go back to containing that key.

As attachment.php already connects to the database, it's probably just as simple to take the project key, grab the original key from the database and then use that when building the file path.

Re-opening to assign to a version

Assigning to v0.01b

Re-Closing