Cannot create sprints with issueFunction in board filter

As soon as ScriptRunner is involved in our board filter, only members of jira-administrators can create sprints anymore. This worked fine before updating to the latest ScriptRunner in our JIRA Software 7.1.4.

Exemplary filter with ScriptRunner in use:

issueFunction in subtasksOf("(project=11000 and issuetype in (10001, 10301, 1) and status!=1) or (project=11000 and issuetype in (10000, 10201))") OR project = 11000 AND issuetype in (10001, 10301, 1) AND status != 1 OR project = 11000 AND issuetype in (10000, 10201) ORDER BY cf[10300]

Atlassian refered me to you, as they checked, that this happens only with ScriptRunners issueFunction in use, i.e.: Manage Sprint-permissions etc. are there and not the problem (see GHS-40733).

Please take a look ASAP, as the next sprint review draws near, and our sprint managers cannot manage sprints at the moment anymore.

Thanks a bunch

17 answers

Ha! I found a solution with keeping the issueFunction-part in the query! Take a look at line 1:

project=11000 AND
issueFunction IN subtasksOf('
    (project=11000 AND issuetype IN (10001, 10301, 1) AND status!=1)
    OR (project=11000 AND issuetype IN (10000, 10201))
OR project = 11000 AND issuetype IN (10001, 10301, 1) AND status != 1
OR project = 11000 AND issuetype IN (10000, 10201)
ORDER BY cf[10300]

This one works like a charm! The question is: Why? The issueFunction's content should be limited to the project in question anyways. Maybe ScriptRunner is trying to look for further issues elsewhere, where the user in question has no rights?

Perhaps a sidenote might help in tracking the problem down: We recently moved some issues from project 11000 to another project (where the user has no rights), so they could be found with both the previous keys (e.g. SC-1234) as well as their new keys (QA-4321). ScriptRunner might perhaps try to follow this notion and try to get hold of the issues in the new project, causing the odd misbehavior?

Wow, that worked like a charm indeed.
So the whole point is to use "AND" to restrict "issuefunction" from keeping the scope of the search outside of the Project, for which we need to have the results.

Thank You Very Much Klaus. :) 
Well Explained. :)

0 votes

Do you have any other scripts that you have run since upgrading, that could change sprints or permissions?

Which versions of ScriptRunner and JIRA did you upgrade from?

JIRA: 7.0.10
ScriptRunner: the one before the current one.

There have been no scripts run I know of. Permissions are perfectly fine (and unchanged long before, during and since the upgrades).

0 votes

Can you go to View all boards > Configure then look at "Ranking" for the filter. I can't create a filter when ranking is disabled and I have a query like below. Is this the case for you?

issueFunction in subtasksOf("project=SSPA") OR issuetype in (10000) AND resolution is not EMPTY ORDER BY cf[10008]

0 votes

If this is the case you will need to change the order by to:

I'm still investigating why this worked before. Did you have the exact same filter query?

The filter works perfectly for everybody, including the sprint masters. It does not matter if I put "Rank" instead of "cf[10300]" in the filter.

In any case, jira-administrators can create sprints in the board with this filter, but even the project administrators cannot, although they have all rights to the project, including "Manage Sprints". This worked before.

0 votes

There was a new manage sprint permission introduced in 7.1.0+. See here

I can't reproduce your problem using those versions listed. It sounds like you will need to give your users this new permission before they can create sprints. I think its just a coincidence your filter uses a ScriptRunner JQL function.

Can you let us know how you get on after that.

0 votes

I don't have access to the original issue you raised with Atlassian, GHS-40733, so i'm not sure if you have already done this.

Well: in GHS-40733, Atlassian already verified, that permissions are not the problem here. It works for them, if the issueFunction-part of the board filter is removed. It does not, if it is there. They even restored a anonymized backup of our instance to verify this.

In short: Permissions are not the problem.

0 votes

What is the error you are seeing? Is it that the create sprint button doesn't appear or is greyed out? Or some other error message?

It is greyed out. I can definitely reproduce this with a dummy account:

As long as the board filter contains the issueFunction-part, the button is greyed out. As soon as it is removed, it works.

Same results were achieved by Atlassian's support.

I think I found a solution by myself (which, however, means getting rid of ScriptRunner-functionality in the board filter, too):

  1. removing the issueFunction-part completely
  2. adding a issuetype in subtaskIssuetypes() instead

This seems to work well. At least it works, while including the ScriptRunner-functionality does not seem to anymore. Maybe you can find the reason sometime.

0 votes

Would you be able to run the following in script console and change the user in the script to one of the users you are having issues with.

You should get a list of sorted issue keys back, are there any missing that you would expect to see with your JQL? If there is it may still be a permissions problem on one of the projects.

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.jql.parser.JqlQueryParser
import com.atlassian.jira.user.util.UserManager
import com.atlassian.jira.web.bean.PagerFilter

def jqlQueryParser = ComponentAccessor.getComponent(JqlQueryParser)
def searchService = ComponentAccessor.getComponent(SearchService)
def userManager = ComponentAccessor.getComponent(UserManager)

// Change to user you are having problems with
def user = userManager.getUserByName("baduser")

def query = jqlQueryParser.parseQuery("issueFunction in subtasksOf('(project=11000 and issuetype in (10001, 10301, 1) and status!=1) or (project=11000 and issuetype in (10000, 10201))') OR project = 11000 AND issuetype in (10001, 10301, 1) AND status != 1 OR project = 11000 AND issuetype in (10000, 10201) ORDER BY cf[10300]")

def searchResults =, query, PagerFilter.getUnlimitedFilter())
def issues = searchResults.issues.collect { issue ->
}.sort().join(", ")


Of course! Did that and compared the results: They are identical, so no news from my side here.


This is something to do with a change in JIRA Software where it analyses the query to work out the affected projects, rather than actually executing it. I can't find the docs on that now but there are extensive docs that I read recently. What you have done is the course of action that they recommend.

After upgrading to JIRA (7.1.9) and Scriptrunner (4.3.13), we seem to have the same problem.
Is there already a fix for this, except for the described workaround.


I had the same problem. It is caused by Jira not being able to determine if you have the required rights when you use issueFunction. You can help Jira determine this by adding a list limiting the projects, i.e. adding to your jql: AND project in (project1, project2, project3)...pretty silly, but it works.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Feb 07, 2019 in Marketplace Apps

A Timeless Love Story

It started as any story starts, on a normal, rainy day.   Admin meets App, and her name was Klok2, and like any first relationship we were both trying to make it work but neither one knew what...

442 views 8 26
Read article

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you