Simple Issue Language™ JQL Configuration

To access the JQL Configuration settings, click the Settings icon in Jira and navigate to Manage Apps > Power Apps Config > Power Scripts > JQL. Here you can define search limits for different user groups. To do this, click the New Limit button and set the following.

• Results Limit — The maximum number of issues that a JQL query will return for users not belonging to any listed group. The default value is 1000.

• Processed Limit — The maximum number of issues that will be processed before search termination for users not belonging to any listed group. This defaults to 10000 for new users and is unlimited for existing users.

• Unlimited — When selected, this option removes restrictions on results and processed issues. Note that this may impact system performance.

• Operations — This table displays the configured values for each user group. You can modify or remove these configurations as needed.

• If a user does not belong to any group or belongs to a group with no limits configured, the system will apply default limits.

Open

Searching issues

One of JQL limitations where users struggle the most is the inability to search for simple expressions. For instance, you can't search for issues where the reporter is the same as the assignee. This is due to the fact that JQL expressions are evaluated once at the beginning of the search and that it accepts only <field> <operator> <constant> expressions in search.

silJQLExpression / expression

Let's see what silJQLExpression can do.

This JQL fragment accepts two parameters: the first one is any SIL™ boolean expression which will be run on each matching issue, the other is a JQL expression used for initial results filtering on which the expression is applied. silJQLExpression can only be applied on issues, it cannot be used to search another object types in Jira.

Starting with version 4.1.1 of Power Scripts™, an alias exists for the silJQLExpression: due to the popular request, we named it expression

However, version 4.1.1 also adds the possibility to pass parameters on the script fragment that you use, so the syntax has become:

We have also added other improvements that you can see on the Pre-Defined JQL Functions page.

In the following example, we're searching for all bugs in the TEST project that have the same user as the reporter and assignee:

This script does the following:

1. Runs the filter JQL, if provided. If empty, it will get all the issues from all the projects to which the user has access.

2. If there are issues, it generates a simple script starting with the expression you provided.

3. For each issue, it runs the script; if expression is true, key is retained.

4. It returns the keys array back to the JQL so it can further processed by some other JQL expressions.

Considering performance during search

Notice that the filtering is of paramount importance, although you can provide an empty string there, this is really not recommended.

For instance, the following JQL is valid and serves the same purpose as above:

However, this is not quite right. The expression will be evaluated on all issues from that TEST project, and this is not really desirable when you have another filter condition to apply. Re-writing it in the first form avoids this, so be cautious when you see clauses linked by AND on the same level as the silJQLExpression construct.

More Complex JQL

You can construct any arbitrary JQL starting with this expression:

silJQL and silJQLList

What if the expression you are looking for is much more complicated? What if the expression is in fact a big chunk of logic and you need to obey to it to find your issues? We introduced two more JQL expressions:

• silJQL

• silJQLList

Both expressions receive the path to a SIL™ file as first argument, and (optionally) parameters to run that script. The difference between them is that silJQL returns a single result, while silJQLList returns a list of results.

Therefore silJQL can use operators like =,  !=, >=, <= ... while silJQLList can use operators like in, not in, and so on.

silJQL - single issue search

Let's see an example to see what these expressions can do. At first, we'll create a script in a file using SIL™ Manager, and name it test.sil.

test.sil

After we saved the file, let's use our newly created script in search:

jql

Performing the search several times, you will see that the searched issue changes, depending on that random value.

You will notice that we passed the project as a parameter to the SIL™ script, and that the file will be resolved normally relative to the root (silprograms). You can pass any parameters you like there. The script runs in the Jira context, and not in the issue context.

silJQLList - multiple issue search

The following example is returning more than one ticket:

test1.sil

Now we'll save it as test1.sil and perform the following JQL:

The results returned will look like the following image:

Open

Performance during search

When you build filtering expressions, keep in mind that the overall performance of the script impacts the search performance.

Other searches with silJQL and silJQLList

Using silJQL and silJQLList you can also get other values, not just issue keys. For instance, consider the following script:

test_issty.sil

If you perform a search using the silJQLList, but you base the query term on the issuetype this time, then the issue types will be filtered from the values returned from that nice SIL™ script.

jql

You can use the same technique with statuses, components, and so on.

Additional notes

Search performance can be further improved either by using Pre-Defined JQL Functions or by using functional indexing, we added both features in the version 4.1.1 of Power Scripts™ for Jira:

Contents

See More