REST error "The value 'XXX' does not exist for the field 'project'."]

[Pat R]

Similar to issue https://jira.atlassian.com/browse/JRASERVER-36370, but I can't figure out how to see that solution!

I'm using Excel VBA (Microsoft XML v6.0 library, MSXML2.XMLHTTP60) to query Jira via the REST API, and if I start from a REST query with a jql clause that returns data correctly using rest/api/2/search, but then add a project filter into the jql, e.g. 'project in (a,b,c)' then the request fails with a return of 400 and a message of "The value 'a' does not exist for the field 'project'." for each of the projects requested.

The project names are correct, and if I paste my request uri into Chrome it works fine and returns data, although it actually fails in Edge with the same error interestingly.

[Andy Heinzer · Accepted solution]

Hi Pat,

That specific error is an indicator that your REST call has not created a session yet.  There is a KB that better explains this in JIRA API with CURL throws error {"errorMessages":["The value 'XXX' does not exist for the field 'project'."],"errors":{}} 

Without a session created, Jira throws this error because without a session, the call has not made any kind of authentication with Jira yet.  Jira can still allow unauthenticated users/calls to result search results, but in cases like that Jira isn't going to divulge the names/keys of projects to unauthenticated users (unless the project has the browse permission opened up to the Anyone group).  Which is why you see an error here that the project does not exist.

I hope this helps,

Andy

[Pat R]

Hi Andy,

Thanks for your help - that fixed it. I was using Basic Authentication, but I didn't realise certain data still wasn't available using that - haven't come across that in the documentation. I assume the reason it works in one browser and not another is because I already had a session open in Chrome.

Thanks,

Pat.

[Yatish Madhav]

Hi Andy and xpatrussel, Please advise how this was resolved? I commented on https://jira.atlassian.com/browse/JRACLOUD-36370 with some details on what I am doing but not sure how to troubleshoot the permissions side as our "system" user is required to view all projects and issues? Thanks in advance.

[Andy Heinzer]

Hi @Yatish Madhav 

In my experience there are few different possible causes for that specific error. 

1. Your REST call is not authenticated
2. Your REST call is authenticating correctly, but your account doesn't have permissions to see that account
3. Your REST call is authenticating correctly, and your account has permissions, but the project doesn't actually exist

When it comes to using REST with Jira, it's usually #1.  Since Jira allows authenticated requests to be made to it, this response is commonly seen when your REST call is not properly authenticated in the way you think it is.

What method of authorization are you using here?  If this is Basic, and you're using Jira Cloud, please see the page Basic auth for REST APIs.  Atlassian deprecated support for using passwords or cookie based methods for basic auth.  But it still supports the use of an API token instead of a password for Basic Auth. 

After you create a token, you then need to build a string of

user@example.com:API_Token

and then base64 encode that string.  You can then use that encoded string and pass it in an authorization header instead of actually supplying username/password directly in your calls.

Let me know if you have any questions about this.

Andy

[Yatish Madhav]

Hi @Andy Heinzer --- Thanks for the above

In your list above, #2 was my case. I.e. the 'system user' that we use for making API calls didn't have access. I added the user with Administrator access to the permission scheme for the project and it worked and the erorr did not return

Though as an on going solution, how can I add/modify the permissions (which permission scheme, etc) for this system user so that it has full browse projects and issues for all projects including new ones created as well?

Thank you in advance

[Andy Heinzer]

Glad to hear that helped. 

But I'm not sure there is a surefire solution long term to always have browse access to all new projects.  Each project in Jira can be configured with its own unique permission scheme as described in Managing project permissions.  When a new project is created, it tends to create its own permission scheme, unless you've created the project from a shared template which is not as common to see.

As long as your account has the Administer Jira permission from the Global permissions, then at least you can always adjust those permissions to give yourself the browse permissions.  But there really is not a way to always make sure that your account has a particular permissions on all newly created projects.

Andy

[Yatish Madhav]

Thanks for the response @Andy Heinzer 

Hmm, I find that a bit hard to believe ... So some background we would like to pull all projects (current and future ones) into our internal system.

There is a cascading dropdown on our system - 1st one pulls all projects and 2nd one pulls all issues under the select project by the project key using JQL.

Now if there are +- 5 projects and multiple issues created under each lets say in the next week - do we need to manually edit the permission schemes for each of those new ones to show on our internal system?

How can this be done?

Thank you

[Andy Heinzer]

The nature of how JQL works is such that, it will only ever show you issues that your account has the permissions to browse.  It simply cannot show you issues when your account does not have permissions or security scheme access to view.  As such, the user account that runs that JQL could return different results from another account running the same query.

It is not certain to me that you will need to edit the permission schemes of each project to get the results you want to see.  But there is the potential that you might have to do just that in order to get back all the issues you want to see here when using JQL. 

Editing the project permissions might be one way to solve this problem you have presented, but it might not be the only one.  For example, if you know that each project is granting browse permission to a particular user group (or project role), then adding that user to that group (or to the project role) is one way you can get the user account making this JQL query to return your desired results.  But again, it comes down to what permissions are being given to each project and the account running the JQL query.

Some administrator will create a single permission scheme and then use that same permission scheme across multiple projects that require the exact same access settings.  In cases like that it tends to make it easier to make adjustments to a number of projects all at once. 

But that said, we still can't know for sure what permission scheme is going to be in use for a yet to be created project.