########################################################################################## JILS-30: Attachments functionality broken ########################################################################################## Issue Type: Bug ----------------------------------------------------------------------------------------- Issue Information ==================== Priority: Major Status: Closed Resolution: Fixed (2016-04-29 15:04:38) Project: Jira Issue Listing Script (JILS) Reported By: btasker Assigned To: btasker Affected Versions: - 0.01b Targeted for fix in version: - 0.01b Time Estimate: 0 minutes Time Logged: 0 minutes ----------------------------------------------------------------------------------------- Issue Description ================== Attachments to recent issues result in a 404. Attachments to older issues still seem to work, suggesting something in the logic is wrong. For example, although the following attachment ID's are available - 11512 - 11516 - 11517 Attachment ID 11513 isn't (and presumably 11514, 11515). Need to try and figure out why ----------------------------------------------------------------------------------------- Activity ========== ----------------------------------------------------------------------------------------- 2015-09-16 12:44:37 btasker ----------------------------------------------------------------------------------------- Within the Issue view page, the link to an attachment is generated by -- BEGIN SNIPPET -- qs2sef("attachment={$attachment->ID}&fname={$attachment->FILENAME}&projid={$issue->pkey}-{$issue->issuenum}"); -- END SNIPPET -- (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. ----------------------------------------------------------------------------------------- 2015-09-16 12:45:19 btasker ----------------------------------------------------------------------------------------- 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. ----------------------------------------------------------------------------------------- 2015-09-16 13:02:57 git ----------------------------------------------------------------------------------------- -- BEGIN QUOTE -- Repo: Jira-Issue-Listing Commit: 58ff4c8dac44578b2cbba6a5c6f5cb774f6b5186 Author: Ben Tasker