Problem with REST API issue search by Custom Field

[Amir Katz (Outseer)]

Background

In our Jira Cloud, we have > 1600 custom fields (don't ask why...). I took upon myself to perform a cleanup of the CFs. I am a Jira admin, of course.

A CF can be deleted if all the below conditions are met:

1. It is not a LOCKED field
2. It is not included in any screens
3. Its Last Used date is empty
4. It does not appear in any issue

Items 1-3 can be viewed in the Jira UI when you go to Settings --> Issue --> Custom Fields and search for your CF by name.

Condition #4 is not readily visible and it requires you to perform a simple JQL search:

"<field-name>" is NOT EMPTY

This is assuming that the field name is unique, which may not be the case, but that's another story...

Problem

The problem that I see that for many CFs, the above search returns an error:

Field 'enVision RCA Fault Code' does not exist or you do not have permission to view it.

When I perform this search with the Jira REST API, using the field ID, the REST API returns 400 ("bad request").

The above field is a single choice select list, so the query is definitely valid.

I know for a fact that this field is not in a team-managed project.

The REST API call payload (for this CF) is {"jql": "cf[11335] is not EMPTY"}

The REST API documentation says that 400 means 'Returned if the JQL query is invalid.'

I get this error for many, many CFs, so I wonder if I'm doing anything wrong.

Thanks.

References

REST API: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-search/#api-rest-api-3-search-get

[Amir Katz (Outseer) · Accepted solution]

Indeed this is a Jira bug.

After working with Atlassian support, I was provided with a workaround, and an official bug was created:

https://jira.atlassian.com/browse/JRACLOUD-79265

My two comments in the bug provide more details and explain the workaround.

The reason that contexts were missing is that after the migration to cloud, we delete many unused projects, and apparently, the contexts referring to them were deleted as well.

So we ended up with more than 400 fields w/o contexts.

[Prince Nyeche]

There seems to be some form of error with your query that why it shows 400 being a client error. When such error occurs it could literally mean you do not have permission to probably browse certain issues that such field returns. Probably worth checking the permissions or project configuration to be certain.

[Amir Katz (Outseer)]

Respectfully disagree...As a Jira admin, I have browse permission to ALL the projects in our Jira instance. So I don't think this is the cause.

Also, if this was the case, I would expect to get some results,  from the projects that I have permission to browse and not get any errors at all.

[Prince Nyeche]

If you're on cloud, you might be surprised that as a Jira Admin if your project uses project role in the permission scheme, you might not have as much permission as you might think. Especially if you're not added as a default member on those project roles. I think the error speaks for itself when it mentions 

does not exist or you do not have permission to view it 

That would be a hint that you should check those areas. At the end, if that's not the case, then you should most definitely reach out to support.

[Amir Katz (Outseer)]

Some updates:

My original code uses the REST API call 'Get Fields Paginated'. It returns ALL fields, 1622 or so.

When I perform the 'search issues', I use the field IDs that I get from the above call. So the first part of the error message ('field does not exist') is definitely not true here.

So I added more code - a new function that invokes the REST API call 'Get Fields' and it returns only 1165 fields, matching the # of fields for which the search API did not return error 400.

This adds weight to what @Prince Nyeche is saying (about the problem being the permissions).

However, we have a small number of permission schemes, most are shared by multiple projects.

I went through all of them and the 'Browse Projects' permission, in all of them, is granted to either 'Application Access - Any logged in user' or to one of two admin groups, both of them I am a member of.

So I wonder if the 'Any logged in user' permission covers API access (I do use my user & API token to authenticate to Jira).

If yes, then it's still a mystery why 100's of CFs are blocked.

One more data point: many of our CFs were migrated from Jira server with some projects, but many of those projects were deleted since they were not in use. Fields used by those projects were not deleted.

So it may be related, or not.

[Amir Katz (Outseer)]

I'm waiting for a few more answers here in the forum. If I don't, I will submit a support ticket to Atlassian.