Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't get attachment contents, seems jira-ruby might be using the wrong endpoint? #414

Closed
morphine00 opened this issue Oct 18, 2023 · 4 comments · Fixed by #422
Closed
Labels
Enhancement Enhancements to existing features
Milestone

Comments

@morphine00
Copy link

Hi there!

I'm trying to fetch an attachment's actual content, as described by this JIRA API documentation. However, despite trying multiple variations of accomplishing this, I can't figure out a way to make it work. Additionally, it seems that my efforts bring up the wrong endpoint. In more detail:

issue = issue.find('MY-ISSUE')
jira.Attachment.find( "10000", issue: MY_ISSUE )

That results in a 405 Method Not Allowed.

jira.Attachment.find( "10000", issue_id: "10101" )

That also resutls in a 405 Method Not Allowed.

After additional digging, it seems that jira-ruby is never querying the actual /attachments/[id] endpoint, but is instead going through the /issue/{issueIdOrKey}/attachments endpoint that seems to have write-only functionality.

Can you folks shed some light on this?

@marlinpierce
Copy link
Contributor

Try this

issue =  JIRA::Resource::Issue.find(client, 'MY-ISSUE', { fields: 'attachment' } )
attachments = issue.attachments.find(10000)
attachment = attachments.first

@morphine00
Copy link
Author

Hi Marlin, and thanks for your reply. The thing is, when you do that, you get the attachment's metadata, but not the actual file's contents. In fact, calling "content" just retrieves a string with the endpoint to be queried, returned by the Jira API, in the form: /rest/api/3/attachment/content/10000 . Unless I missed something in the source, jira-ruby library apparently doesn't query that endpoint at all to retrieve a file's contents.

My current workaround is to monkey-patch the Attachment class with a get_content function like so:

module JIRA
	module Resource
		class Attachment < JIRA::Base

			# Returns an attachment's contents in the form of a temporary file in order to avoid hold the data in RAM
			# It's up to the caller function to close the file handle.
			def get_content

				# "redirect=false" to avoid the possibility of the built-in CGI client not following redirects
				url = client.options[:rest_base_path] + "/attachment/content/#{CGI.escape( id )}?redirect=false"

				# TODO: handle error conditions here, see https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-attachments/#api-rest-api-3-attachment-content-id-get
				begin
					response = client.get( url )
				rescue JIRA::HTTPError
					return nil
				end

				# TODO: handle error conditions here
				tempfile = Tempfile.new('jira_attachment', binmode: true )

				tempfile.write( response.body )

				# Rewind the file location pointer else when the caller function tries to read the file, it'll get nothing
				tempfile.seek(0, IO::SEEK_SET)

				return tempfile
			end
	end
end

@marlinpierce
Copy link
Contributor

I think that is correct. You get the "content" field which is a URL to download the contents. This is how the Jira REST API works, so as a wrapper around the REST API , the jira-ruby gem does the same. I agree and convenience method to get the content might be nice.

@marlinpierce
Copy link
Contributor

I have a PR #422 which implements a convenience method to download the attachment file contents.

@bobbrodie bobbrodie linked a pull request Apr 1, 2024 that will close this issue
@bobbrodie bobbrodie added this to the v3.0.0 milestone Apr 2, 2024
@bobbrodie bobbrodie added the Enhancement Enhancements to existing features label Apr 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement Enhancements to existing features
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants