[Jira] "Agile" methods don't use the “api_root” instance attribute, as most other methods do

[super-vanilla-bear]

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

[super-vanilla-bear]

So, as I said, I can take it and make a PR, if it's really an issue and not my misunderstanding of the structure/concept :)

[gonchik]

@super-vanilla-bear sure, please provide a PR

[super-vanilla-bear]

I'm closing the issue as it is, in fact, the preliminary description of this PR: #1530, which was already merged.

[gonchik]

@super-vanilla-bear Thank you very much