# Jira: New JQL search API allows searching for trashed fields. Intended? **URL:** \ **Category:** Jira Cloud\ **Tags:** rest-api-search\ **Created:** [December 4, 2024, 2:56pm UTC](https://community.developer.atlassian.com/t/jira-new-jql-search-api-allows-searching-for-trashed-fields-intended/86874 "2024-12-04T14:56:21Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![AndreasEbert](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/andreasebert/32/38902_2.png) [@AndreasEbert](https://community.developer.atlassian.com/u/AndreasEbert)\ **Post date:** [December 4, 2024, 2:56pm UTC](https://community.developer.atlassian.com/t/jira-new-jql-search-api-allows-searching-for-trashed-fields-intended/86874/1 "2024-12-04T14:56:21Z")
Since ~1 month the [new JQL search REST API _/rest/api/latest/search/jql_ is available](https://developer.atlassian.com/changelog/#CHANGE-2046). 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](https://community.developer.atlassian.com/t/rfc-61-evolving-search-capabilities-addressing-scalability-with-a-new-enhanced-search-api/83027). 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 ❌ ---
**Author:** ![glewandowski](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/glewandowski/32/51699_2.png) [@glewandowski](https://community.developer.atlassian.com/u/glewandowski)\ **Post date:** [December 5, 2024, 7:47am UTC](https://community.developer.atlassian.com/t/jira-new-jql-search-api-allows-searching-for-trashed-fields-intended/86874/2 "2024-12-05T07:47:57Z")
> [@AndreasEbert](#): > > /rest/api/latest/search/jql?jql=cf[XXXXX] ~ foo 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: ```auto rest/api/latest/search?jql=cf[XXXX]%20~%20foo&validateQuery=none ``` If you need to validate the query, there’s another [endpoint](https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-jql/#api-rest-api-2-jql-parse-post) available ```auto POST /rest/api/2/jql/parse { "queries": [ "cf[XXXX] ~ foo" ] } ``` Alternatively, you can retrieve all fields in Jira via `rest/api/3/field` . [Docs](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-fields#api-rest-api-3-field-get) ---
**Author:** ![AndreasEbert](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/andreasebert/32/38902_2.png) [@AndreasEbert](https://community.developer.atlassian.com/u/AndreasEbert)\ **Post date:** [December 5, 2024, 8:30am UTC](https://community.developer.atlassian.com/t/jira-new-jql-search-api-allows-searching-for-trashed-fields-intended/86874/3 "2024-12-05T08:30:22Z")
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. ---
**Author:** ![glewandowski](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/glewandowski/32/51699_2.png) [@glewandowski](https://community.developer.atlassian.com/u/glewandowski)\ **Post date:** [December 6, 2024, 7:42am UTC](https://community.developer.atlassian.com/t/jira-new-jql-search-api-allows-searching-for-trashed-fields-intended/86874/4 "2024-12-06T07:42:21Z")
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. ---
**Author:** ![glewandowski](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/glewandowski/32/51699_2.png) [@glewandowski](https://community.developer.atlassian.com/u/glewandowski)\ **Post date:** [December 9, 2024, 9:37am UTC](https://community.developer.atlassian.com/t/jira-new-jql-search-api-allows-searching-for-trashed-fields-intended/86874/5 "2024-12-09T09:37:18Z")
@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](https://jira.atlassian.com/browse/JRACLOUD-85420)