Jira: New JQL search API allows searching for trashed fields. Intended?

Jira Development Jira Cloud
1

Since ~1 month the new JQL search REST API /rest/api/latest/search/jql is available. I just found that – in contrast to the old, deprecated API /rest/api/latest/search – it allows trashed custom fields in the JQL query. Is that intentional?
I stumbled over it while looking into how to change my app to the new REST API. This might be a problem for me, because my app should detect if a custom field known to it by ID is still available for searching and updating. Currently, we detect this by checking for the well-known error message when used in a JQL search. That check would break with the new REST API if it doesn’t return an error.
@glewandowski, tagging you because you posted initial RFC-61.

Steps to reproduce:

  1. Create a text custom field (and make it available in a project)
  2. In an issue set value “foo” for that custom field.
  3. Use old REST API with /rest/api/latest/search?jql=cf[XXXXX] ~ foo → Issue is found, as expected
  4. Use new REST API with /rest/api/latest/search/jql?jql=cf[XXXXX] ~ foo → Issue is found, as expected
  5. Trash the custom field.
  6. Use old REST API with /rest/api/latest/search?jql=cf[XXXXX] ~ foo → Error Field 'cf[XXXXX]' does not exist or you do not have permission to view it, as expected
  7. Use new REST API with /rest/api/latest/search/jql?jql=cf[XXXXX] ~ foo → Issue is found, NOT expected :x:
2

I believe the issue you’re encountering is related to JQL validation, which is disabled for new endpoints. It’s not related to trashed custom fields. You can verify this by calling the old endpoint with the validateQuery=none parameter:

rest/api/latest/search?jql=cf[XXXX]%20~%20foo&validateQuery=none

If you need to validate the query, there’s another endpoint available

POST /rest/api/2/jql/parse
{
    "queries": [
        "cf[XXXX] ~ foo"
    ]
}

Alternatively, you can retrieve all fields in Jira via rest/api/3/field . Docs

1 Like
3

Ah, interesting. I didn’t know about validateQuery=none. Good to know.
Setting that on the old endpoint does indeed prevent the error message, i.e. validation. But there’s still a difference:

  • Old endpoint, with validateQuery=none: Does not find issues when searching for a trashed field.
  • New endpoint: Does find issues when searching for a trashed field.

So, I guess the search-index still has data for trashed fields (makes sense; otherwise un-trashing them wouldn’t work so fast), and the new endpoint accesses this data, but the old endpoint – even with validateQuery=none – does not.

4

I understand your point now. I will take this to the appropriate team for investigation. It may take some time. Thank you for your patience.

1 Like
5

@AndreasEbert , this is indeed a bug in the new service. Trashed custom fields shouldn’t be visible in search results. I raised it here: https://jira.atlassian.com/browse/JRACLOUD-85420

1 Like