rest/agile/1.0/issue/ 403 error when accessing fields=customfield_10009 programatically

[Jerry Laster _Divim_ Inc__]

Hi,

I can access rest/agile/1.0/issue/{IssueID}?fields without a problem.

I can also access rest/agile/1.0/issue/{IssueID}?fields=?fields=customfield_10009 on the browser.

However, when I try to access ?fields=?fields=customfield_10009 programmatically I receive a 403 response. 

On a related note. 

How can I find the rank on the backlog of an item? 

The custom field shows info like:

0|i01l3b:

What's the notation?

Thanks,

Jerry

[Earl McCutcheon · Accepted solution]

Hello Jerry,

The 403 code means "unauthorised", indicating permissions are not granted to the user running the request. 

You noted running the command from the browser but when doing the API call it is failing, are you running the API request as the same account? Also, can you share the full syntax of the call you are running.

One thing I did notice in the formatting is that you are using the GET /rest/agile/1.0/issue/{issueIdOrKey} syntax for earlier Jira+Agile versions rather than the current GET /rest/api/2/issue/{issueIdOrKey} Syntax, So depending on what Version of Jira are you currently on as the syntax will vary slightly.

But I ran a quick test on on Jira 7.6 and was successfully calling both the endpoints with curl in the following syntax:

curl -k -D- -u user:pass -X GET -H "Content-Type: application/json" http://<BASE_URL>/rest/API/2/issue/{issueIdOrKey}?fields=customfield_#####

curl -k -D- -u user:pass -X GET -H "Content-Type: application/json" http://<BASE_URL>/rest/agile/1.0/issue/{issueIdOrKey}?fields=customfield_#####

Noting the search criteria only passes fields in once as using the "?fields=?fields=customfield_#####" causes the value of the field to be excluded, but no 403 errors were triggered.

Next it looks like customfield_10009 is your Rank Field, and in regards to the formatting of the fields output, this variable is not meant to be human readable, and is built on the lexicographical order of strings to determine the ranking of issues the Non human readable rank values are meant for the backend calculations; and as machine language is concerned this provides a dramatically increased calculation performance human readable rank values would increase the system overhead dramatically to arrange the issue order on a ranking event.

Looking at the value you noted "

0|i01l3b:

the "0" is the current Bucket Distribution of the issue of values 0, 1, or 2, Used to run a periodic balancing operation to conserve on performance cycles. The lexographical rank "i01l3b" is the current balanced ranked Position and the ":" is the break point for Unbalanced operations or the live ranking calculations up to a hash length of 254 characters.

i.e. if you have values "0|i01l3b:" and "0|i01l3c:" and rank an issue between the two the issue, the issue that was ranked in-between will gain an additional hash "0|i01l3b:a" to act as an intermediary placeholder with the order defined "0|i01l3b:","0|i01l3b:a","0|i01l3c:", until the rebalance operation can occur to set the order to "0|i01l3b:","0|i01l3c:","0|i01l3d:" on these issues.  A quick comparison the ranking operation can do calculation rang of 1.844674407371E+19 per cycle with the same amount of overhead as ~99 human readable rank operations.

We do have a Feature Request to make a human readable Rank value tracked here:

• https://jira.atlassian.com/browse/JSWSERVER-15444

But Depending on what you are trying to do with the rank value programmatically it may not be obtainable, so what is your ultimate goal here as there may be a better alternative than collecting the RAW rank value.

Regards,
Earl

[Jerry Laster _Divim_ Inc__]

Hi Earl,

Thanks a lot for the detailed information. I don't need the field to be human readable, but I need to be able to make sense of the place on the backlog of any issues. For example, I want to check the first n issues on the backlog, and the first n issues on each sprint. I think that the current response is giving me first the issues in the backlog, followed by issues in sprints and putting at the end issues in past sprints, (that's my current impression, but I haven't done extensive testing on this yet). 

Understanding the logic of the notation helps a lot. 

Any better ways to get the first n issues, and the last n issues of the backlog?

With regards to the 403 error, it's a funny thing because the same app with the same privileges and the same read scope will produce when running 

AP.request(uri...

/rest/api/2/issue/10830 = 200

/rest/api/2/issue/10830?fields = 200

/rest/api/2/issue/10830?fields=customfield_10009 = 403

However, if I curl /rest/api/2/issue/10830?fields=customfield_10009 I get 200. 

Any clues about why this may happen? 

Thanks!

Jerry

[Earl McCutcheon]

Hi Jerry,

I think the best option for that is to use a filter in a API issue search result set pulling the data using the Rank:

/rest/api/2/search?jql=<FILTER HERE>&maxResults=#

Please see this doc for some examples on passing JQL via API:

• JIRA Developer Documentation : JIRA REST API Example - Query issues

Noting that the Filter needs to have the spaces modified in the URL so as an exe for the filter: "project = TEST AND resolution = Unresolved  and Sprint not in openSprints() ORDER BY Rank ASC" , which is open issue not in a sprint in project test, for a representaiton of backlog,  I could use the following to get the issue data on the top five ranked issues using that filter:

curl -D- -u username -X GET "http://<base_URL/rest/api/2/search?jql=project=TEST+AND+resolution=Unresolved+and+Sprint+not+in+openSprints()+ORDER+BY+Rank+ASC&maxResults=5"

and modify ASC to DESC to get the bottom five

Regards,
Earl