Description
While building an application that implemented Atlassian OAuth2 (3LO) authorization, I encountered a situation where the two methods I used for Jira entities behaved differently - one worked, and the other returned a 404 error. These methods are Jira().jql and Jira().get_all_sprints_from_board correspondingly.
A feature of initializing the Jira client with a token obtained via the OAuth2 flow is that the addresses that should be used to make API calls differ from the "standard" one, so as described in this document:
instead of https://your-domain.atlassian.net/rest/api/2/{api_endpoint}
you should use https://api.atlassian.com/ex/jira/{cloudid}/rest/api/2/{api_endpoint}
The Jira client may be initialized with OAuth2 creds, and moreover, it accommodates the address feature mentioned above, namely, by passing api_root=f'/ex/jira/{cloudid}/rest/api' instead of using the default value of api_root="rest/api" on its init.
And this allows you to successfully send requests using the Jira().jql method, since it calls the Jira().resource_url method inside, which takes into account the value of Jira().api_root
At the same time, the Jira().get_all_sprints_from_board method, like all the methods next to it, located in the informal "Agile (Formerly Greenhopper) REST API" section, uses hardcoded paths that ignore the possible need to have a non-standard path prefix.
So, to summarize, the standard behavior of the Jira().get_all_sprints_from_board method generates the following URL path:
'rest/agile/1.0/board/{board_id}/sprint'
Whereas (to be functional in the described circumstances) it should be the following:
'ex/jira/{cloudid}/rest/agile/1.0/board/{board_id}/sprint'
The situation is similar to #744 , and for another method section in the Jira class, namely "Tempo Account REST API".
This ticket is to some extent a question, is this the expected behavior and can I miss something, or is this not the expected behavior?
If the latter, I could create a PR with a fix for this