Cannot create sprints with issueFunction in board filter

[kk]

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
Klaus

[kk]

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?

[Manish V]

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. :)

[Shaun Grose]

Hmmm, having the same issue as described, but unfortunately I can't limit the search to a single project. Our IT team is structured with a project per team, which allows us to manage our own workflows and custom fields within our context. However, there are scenarios when Team A needs to do some work for Team B, so the PM's will get together and create a task in Team A's project (to adhere to their workflow, boards, etc), but linked to Team B's Epic.

In order for B's Epic to be shown correctly as a swimlane, we would want to have the Epic from Project B to be included on Team A's board while the work is in progress. Hence using something like IssueFunction epicsOf ("project = A AND blahblahblah...") in the filter.

We have a bunch of teams with their own projects, so ideally I'd prefer not to have to manually list each one in the filter query... But I'll give this a try and report back.

[bauerprocessconsulting]

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.

[Marc De Boeck]

Hi,
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.

Tx,
Marc

[Jamie Echlin _ScriptRunner - The Adaptavist Group_]

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.

[kk]

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

[adammarkham]

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.bc.issue.search.SearchService
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 = searchService.search(user, query, PagerFilter.getUnlimitedFilter())
def issues = searchResults.issues.collect { issue ->
    issue.key
}.sort().join(", ")

issues

[kk]

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.

[kk]

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.

[adammarkham]

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?

[kk]

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.

[adammarkham]

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.

[adammarkham]

There was a new manage sprint permission introduced in 7.1.0+. See here http://blogs.atlassian.com/2016/02/jira-software-sprint-permissions/

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.

[kk]

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.

[adammarkham]

If this is the case you will need to change the order by to: https://confluence.atlassian.com/agile/jira-agile-user-s-guide/configuring-a-board/enabling-ranking

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

[adammarkham]

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]

[kk]

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).

[adammarkham]

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?