Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Problem with REST API issue search by Custom Field



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...


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.





3 answers

1 accepted

Indeed this is a Jira bug.

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

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.

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.

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.

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.

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.

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

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Jira Software

Upcoming changes to epic fields in company-managed projects

👋 Hi there Jira Community! A few months ago we shared with you plans around renaming epics in your company-managed projects. As part of these changes, we highlighted upcoming changes to epics on...

14,818 views 37 48
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you