Issue with getIssuesFromProjects

[Adolfo Casari]

Hi Fidel,

I am getting a performance issue with this expression:

count(filterByStatus(filterByPredicate(getIssuesFromProjects(%{00018}), ^%{00014} != "TareaProyecto"),"Cerrado,Cancelado,Rechazado"))=count(filterByPredicate(getIssuesFromProjects(%{00018}), ^%{00014} != "TareaProyecto"))

It's going throu 4.100 issues in a particular project to check the condition and this is causing the page to take about a minute to load and a transition to fail with a communication breakdown timeout. In other projects it works OK, since the number of issues is significantly less.

This is JWT 2.2.14

Is there any improvement with getIssuesFromProjects in a newer version?

[Adolfo Casari]

I found the solution:

count(issuesFromJQL("project = " + %{00018} + "AND issuetype != TareaProyecto AND status in (Cerrado,Cancelado,Rechazado)")) = count(issuesFromJQL("project = " + %{00018} + " AND issuetype != TareaProyecto"))

[Fidel Castro Armario]

Hi Adolfo,

Sorry, but function getIssuesFromProjects() should be avoided, using issuesFromJQL() instead, trying to filter so much issues as possible, as recommended at: Issue List Examples.

The problem is that issue lists data types are actually created in memory by the parser, and getIssuesFromProjects() usually returns a very big number of issues.

Another problem is that filterByPredicate() is quite time consuming, since it runs a parser for evaluating each predicate. This is not a problem when used with a moderate number of issues, but when applied on all the issues of a project it might be problematic.

You can replace you current expression by this super-fast one:

count(issuesFromJQL("project = " + %{00018} + " AND issuetype != TareaProyecto AND status not in (Cerrado, Cancelado, Rechazado)")) = 0

[Adolfo Casari]

Thanks for your support.

[Adolfo Casari]

Fidel, I reopended this because I would like to ask you if you know when JIRA actually evaluates conditions. In this case it makes sense that the issue page took about a minute to load, since Jira needs to check each and every transition (including the one with getIssuesFromProjects() condition ). But when the page was loaded, the user clicked on transition X that didn't have getIssuesFromProjects() condition (this was in another transition). In this case Jira showed the progress bar and then fails with a comunication breakdown error. This seems to indicate that Jira re-evaluated all conditions again... Can you comment?

[Fidel Castro Armario]

Each time you load the issue detail page of a particular issue, all the conditions of the transitions with origin in issue's current status are evaluated, since conditions are used to decide whether a transition is shown or hidden in the issue detail page.

[Adolfo Casari]

That's correct, but in this case the page was loaded and user was clicking on a transition that didn't have the getIssuesFromProjects() condition ... and then Jira freezed. getIssuesFromProjects() was in another transition not shown since that condition was not true for this particular issue.

Now all is working OK after changin from getIssuesFromProjects() to issuesFromJQL

[Fidel Castro Armario]

The destination status of the transition the user executed surely had a transition with a condition using getIssuesFromProjects(). Isn't it?

[Adolfo Casari]

I attached the screenshots.

User was clicking Modificar, then jira freezes. After changing from getIssuesFromProjects() to issuesFromJQL in Cerrar, it worked OK. It took me a while to find it out, since in other issues this worked ok, because the number of issues returned by getIssuesFromProjects() was low, but in this one it has over 4K issues. This is why I am curious, since as you I expected Jira to check condicionts only when loading the page ( the page took about 1 minute to load), but this would suggest it check conditions when the user clicks on transitions also.

What would happen if you load an issue with a condition that is true at the moment it is loaded, but that changes when the transition is actually clicked (for instance another user changed a customfield value used in a condition while the user had the issue open in his browser)

[Fidel Castro Armario]

Yes, I already knew that but didn't understand the scenario you were describing. Indeed, JIRA checks conditions when a transition is executed, and it may happen that the condition becomes false due to a value entered or edited in transition screen.

Example: you have condition %{10000} = null and validator %{10000} != null. You use transition screen for setting field %{10000}. Although the validator is true, the transition will not be executed since the condition is becoming false. In order to implement that behavior you should use the following condition: %{10000} = null OR hasChanged(%{10000}). With that second condition will pass, since it keeps being true after setting %{10000} due to the field has changed in transition screen.

By the way, since version 2.2.24, condition "A field is/isn't initialized" uses a special mechanism in order to workaround this problem.

[Adolfo Casari]

Thanks for your support.