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

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