Need to query for default filter's JQL text

Question

Recently we implemented a feature on our JIRA (through ScriptRunner) by adding a "Custom web item" button which triggers the execution of a "Custom REST endpoint" so that it can read the query string parameter for the "jql=" value and then generates a static web page which contains "batches", each batch is a hyperlink to download 1000 issues. Something like this:

https://(domain)/sr/jira.issueviews:searchrequest-csv-current-fields/temp/SearchRequest.csv?jqlQuery=(jql-text)&tempMax=1000&pager/start=(page-offset)

It works well when the user explicitly types the JQL text into the search box, because its content will be copied to the browser address box and thus becomes the "jql=" value, like so:

https://(domain)/issues/?jql=(jql-text)

And thus our code can get it from the "jql=" parameter and proceed to produce the web page. If However the user selects from one of the filters, there's no "jql=" parameter, but "filter=" instead, like so:

https://(domain)/issues/?filter=(filter-ID)

Our code can still look up the JQL text string by means of calling this: searchRequestService.getFilter(new JiraServiceContextImpl(user), id).query.queryString

It almost works... At least most of the times, except when the user selects from one of those system default filters such as "My open issues" / "Reported by me", etc.  When they are selected (so far 9 of them in total) the ID is always a negative value (from -1 to -9) and when that value is passed to the getFilter(user, id) function, it always returns null.

I have searched for the JIRA API docs:

https://docs.atlassian.com/software/jira/docs/api/7.5.3/overview-summary.html

... and can't seem to find a function or class/interface to deal with matching the negative filter ID to the default system filters. Currently we just do it the hard-coded way, such as mapping "-1" to "assignee = currentUser() AND resolution = Unresolved order by updated DESC" and "-2" to "reporter = currentUser() order by created DESC", etc. But that kind of hard-coding style is a symptom of "code smell", and apparently if JIRA changes the JQL for those default filters (maybe in a future upgrade), our current code needs to change as well (provided we know JIRA has changed it) or else there will be a problem: what user selects is not what our code exports.

So, may I ask if there's any place in JIRA API where I can find a way to query for the JQL text for those default filters? Thanks in advance for any reply you can provide.

Ignacio Pulgar · Answer

I understand. Certainly, hardcoding should be avoided.

I'd suggest opening a new feature request here.

You may include a link to this question, as well as the URL to the issue here so that I can vote for it.

I've looked for a similar feature request but have found nothing.

If you are on Jira Server, there's also a workaround for hiding those default filters with negative ids:

https://jira.atlassian.com/browse/JRACLOUD-32958?focusedCommentId=1394702&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-1394702

https://jira.atlassian.com/browse/JRASERVER-32958?focusedCommentId=607066&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-607066

However, I'd say those workarounds are kind-of moving the crappy solution somewhere else...

Tony Chu_2m7d17 · Answer

No problem. It is always welcome to hear from fellow JIRA users who can contribute some thoughts.

To give you a better idea why I think using hard-coded style is bad, this is my current solution:

final predefinedFilters = [
    1L: 'assignee = currentUser() AND resolution = Unresolved order by updated DESC', // My open issues
    2L: 'reporter = currentUser() order by created DESC', // Reported by me
    3L: 'issuekey in issueHistory() order by lastViewed DESC', // Viewed recenty
    4L: 'order by created DESC', // All issues
    5L: 'resolution = Unresolved order by priority DESC,updated DESC', // Open issues
    6L: 'created >= -1w order by created DESC', // Created recently
    7L: 'resolutiondate >= -1w order by updated DESC', // Resolved recently
    8L: 'updated >= -1w order by updated DESC', // Updated recently
    9L: 'statusCategory = Done order by updated DESC', // Done issues
]

@BaseScript CustomEndpointDelegate delegate
export1000(httpMethod: 'GET') { MultivaluedMap queryParams, String body ->
    def user = ComponentAccessor.jiraAuthenticationContext.loggedInUser
    def jql = queryParams.getFirst('jql') as String
    if (!jql) {
        def id = queryParams.getFirst('filter') as Long
        if (id) {
            if (id < 0) {
                jql = predefinedFilters[-id]
            } else {
                def searchRequestService = ComponentAccessor.getComponent SearchRequestService
                jql = searchRequestService.getFilter(new JiraServiceContextImpl(user), id)?.query?.queryString
            }
        }
    }
    // make use of jql variable here...
}

As you can see my code already tries to get the jql string from the URL query string. If it's absent, then it tries to resolve the jql from searchRequestService which works as long as the filter ID is not negative (I double-checked that and I'm very certain when the ID is negative the getFilter() always returns null). In that case, the code has no other choice but to look up from the map predefinedFilter, which is hard-coded. And that is not good because nobody can be 100% sure if the next JIRA upgrade will change those predefined filters' jql or not.

Ignacio Pulgar · Answer

My answer meant to be a workaround just slightly more elegant than hardcoding the entire JQL.

mapping "-1" to "assignee = currentUser() AND resolution = Unresolved order by updated DESC" and "-2" to "reporter = currentUser() order by created DESC", etc

Instead of mapping -1 to "assignee = currentUser() AND resolution = Unresolved order by updated DESC", I thought you might had mapped it to "filter=-1".

However, I've just checked that, while "filter=n" works as valid JQL text, "filter=-n" doesn't.

That said, the workaround I initially thought it could be possible, it actually can't help you. Sorry for that!