Dashboard not displaying correct result due to 'Resolution' field

[Aditi Jain]

Users are raising issues that the filter criteria that was working fine till last 2 weeks are not showing the correct result now due to the "Resolution'' field.

I'm not able to identify the exact cause here, one user has raised the issue that the dashboards based on the below query were running correctly 2 week back until 19th Dec but now after coming back from his holidays, its not working as expected (like it was giving results earlier)

This query retrieves only 6 results when 'resolution = Unresolved' is added:
(project = "Global Markets IT" OR labels = GM2019) AND Status not in (Cancelled, Closed, "moved to production") AND resolution = Unresolved

And, 187 result, if 'AND resolution = Unresolved' is removed from the query

User is adamant, that the dashboard created based on this query was retrieving the results correctly earlier and not now.

What can be the possible cause for this. Snapshot attached for  your reference.

Thanks.

[Ollie Guan · Accepted solution]

Hi @Aditi Jain ,

Contact your system administrator to try rebuilding the index.

https://confluence.atlassian.com/adminjiraserver085/search-indexing-981155548.html

By the way, has the workflow been modified recently?

[Aditi Jain]

No changes in the workflow. And, I'm myself the system admin

[Aditi Jain]

Re-Indexing will slow down the instance, so checking if other options can be work out

[Ansar Rezaei]

Hi

I had the same issue before. Atlassian show "Unresolved" Value if resolution filed contain no Value, e.g Empty.

If you edit the end of first JQL to this (Resulotion = Unresolved or Resolution is Empty) you get the result of second query.

The best you can do is clear resolution field for that 6 issues using Adaptivist Script runner and then delete Unresolved value for resolution field

[Nic Brough -Adaptavist-]

Could you get us the count of issues for a third query?

(project = "Global Markets IT" OR labels = GM2019) AND Status not in (Cancelled, Closed, "moved to production") AND resolution is empty

There are a couple of ways to get this problem, and the count of issues for this third query will rule one out, or strongly suggest it is one specific one of the causes

[Aditi Jain]

It's retrieving '7' issues only (means like earlier '6', one issue is added now)

[Nic Brough -Adaptavist-]

Ok, that rules out the thing I was thinking of.

But it also leaves us with the next question - what is actually wrong with the report?   You get 187 reults that match the first two clauses, and that narrows down to 6 (7 now) when you exclude the resolved issues from it.  So what is the actual expectation and where is this incorrect?

[Aditi Jain]

Actually, even I checked this, list of issues with 187 results contain several  issues with Resolution value as 'Unresolved', so that's where the question arises then why are these issues not appearing on adding  'resolution = Unresolved'

[Nic Brough -Adaptavist-]

Ok, I'm pretty sure I know what is wrong.

As an admin, can you go to Admin -> Issues -> Resolutions and look at the list of resolutions you have? 

Specifically, is there one named "Unresolved"?

[Petr Papousek]

@Aditi Jain could make the expected number of results a bit more specific, than "several"? :-)

[Petr Papousek]

@Nic Brough -Adaptavist- I guess there won't be a resolution called "Unresolved", as JIRA displays the "real" Resolution field values using normal text, but a "virtual Unresolved" value (where resolution is in fact EMPTY) using italic

As I look to Aditi's screenshots, the Resolution values are in italic, so i guess it's just a virtual Unresolved and the resolution is in fact empty

[Ansar Rezaei]

I said the same below. You should remove Unresolved value to prevent this happen again in future.

[Aditi Jain]

Dear Nic, 

We do have multiple values defined there AND NOT 'unresolved' :(

Dear Ansar,

Tried the option provided by adding empty but its not helping.

Also, deleting the value won't be feasible.

The main issue here is, the user was able to see the correct result with the same query just few days back and now he's not. So, that's where I'm wondering what could have happened as from the settings point of view nothing has been changed. Even workflows everything.

[Aditi Jain]

In addition to this, was just working on one more user query, then find out even there as well. Resolution field when put in filter is not retrieving correct result.

Recently only, coming through such issues, never find this out earlier.

[Nic Brough -Adaptavist-]

I need to take a step back and ask you to give us the numbers again.  One of your comments said "Actually, even I checked this, list of issues with 187 results contain several issues with Resolution value as 'Unresolved'" which it should, but suggests you are getting different numbers from each query.

So, in one go, could you give us the number count from :

• (project = "Global Markets IT" OR labels = GM2019) AND Status not in (Cancelled, Closed, "moved to production") AND resolution is empty
• (project = "Global Markets IT" OR labels = GM2019) AND Status not in (Cancelled, Closed, "moved to production") AND resolution = Unresolved
• (project = "Global Markets IT" OR labels = GM2019) AND Status not in (Cancelled, Closed, "moved to production")
• (project = "Global Markets IT" OR labels = GM2019) AND resolution is empty
• (project = "Global Markets IT" OR labels = GM2019) AND resolution = Unresolved
• (project = "Global Markets IT" OR labels = GM2019)

[Aditi Jain]

Dear Nic,

Please find the attachments for the queries above:

[Aditi Jain]

• (project = "Global Markets IT" OR labels = GM2019) AND Status not in (Cancelled, Closed, "moved to production") AND resolution is empty: 11 issues
• (project = "Global Markets IT" OR labels = GM2019) AND Status not in (Cancelled, Closed, "moved to production") AND resolution = Unresolved: 11 issues
• (project = "Global Markets IT" OR labels = GM2019) AND Status not in (Cancelled, Closed, "moved to production"): 188 issues
• (project = "Global Markets IT" OR labels = GM2019) AND resolution is empty: 11 issues
• (project = "Global Markets IT" OR labels = GM2019) AND resolution = Unresolved: 11 issues
• (project = "Global Markets IT" OR labels = GM2019): 372 issues

[Aditi Jain]

(project = "Global Markets IT" OR labels = GM2019) AND Status not in (Cancelled, Closed, "moved to production") and resolution not in (Unresolved)

[Aditi Jain]

Sorry, forgot to mention that the query :

(project = "Global Markets IT" OR labels = GM2019) AND Status not in (Cancelled, Closed, "moved to production") and resolution not in (Unresolved) results in 6 issues

When When Query: (project = "Global Markets IT" OR labels = GM2019) AND Status not in (Cancelled, Closed, "moved to production") is giving 188 result

[Petr Papousek]

@Aditi Jain, so you appearently get the same number, 11 issues, for both "resolution is empty" and "resolution = Unresolved"

but still, what number of results do you expect? :-) why is 11 wrong? what is the "correct result" you are expecting?

[Aditi Jain]

Dear Petr,

The point here is that when the filter criteria with 'Resolution' field as 'unresolved is added, its not giving correct result. The reason why I'm sure of this is because as I mentioned it earlier as well that when this filter criteria is removed then on matching the no. of issues than many other issues too have the 'unresolved' status but they are not displayed when queried with the filter 'Resolution' as 'unresolved'.

Also, if you see immediate above two queries sent by me, (also as below) this explains what I'm trying to say:

(project = "Global Markets IT" OR labels = GM2019) AND Status not in (Cancelled, Closed, "moved to production") and resolution not in (Unresolved) results in 6 issues

(project = "Global Markets IT" OR labels = GM2019) AND Status not in (Cancelled, Closed, "moved to production") and resolution in (Unresolved) gives 11 issues

When When Query: (project = "Global Markets IT" OR labels = GM2019) AND Status not in (Cancelled, Closed, "moved to production") is giving 188 result

Hope you got my point now?

[Aditi Jain]

Also, to add, this is not specific to any project. While working on this issue find out that this is happening across JIRA

[Aditi Jain]

When a filter Resolution is added anywhere, it's not giving correct result.

[Aditi Jain]

Just to highlight one more thing here, if the status of any existing issue is changed then it is adding up in the list of filter with Resolution = 'Unresolved'.

Likewise, noticed few issues that were not appearing until yesterday are appearing today, on checking find out that the status of these issues have been changed to some new value like Design to Development

[Lukas Payer]

Hi Guys,

we are experiencing a similar Problem but with the assignee Field, not with Resolution Field.

In our Workflows, the ReIndex Post Function is present (was before too).

An Background Reindex solved the Problem but we face that Problem nearly every day.

I cannot execute the Background Reindex every day as i have other Problems too ;)

In my Opinion it looks like the ReIndex Post Function dont do its Job.

Is there anyone who knows whats going on?

Best Regards,

[Nic Brough -Adaptavist-]

Could you show us the list of post-functions you have on the transition where the indexing appears to be failing?

[Lukas Payer]

Hello,

yes, here's the screenshot.

As far as i checked all Workflows have the PostFunction "ReIndex...".

Best Regards

[Nic Brough -Adaptavist-]

Ok, that mostly looks ok, but I have a doubt about 1 and 3 and would like to look at the exact symptoms.

On an issue affected, before the manual re-index, what is the assignee set to, and what does the search return?  Feel free to use fake names like:

Assignee was Alice before transition, the transition should change it to Bob (the project lead), and that is what is in the index (search), but when we look at the issue, the assignee is Charlie.

Obviously, that may not be what you are expecting or what happens to you, but I've taken a guess (as I have seen this one before).  It is only an example of what sort of thing I'm looking for.

[Lukas Payer]

1 and 3 are not in use in the affected project.

1 is an external service which changes the assignee to the user which is set in an user picker field named "Owner".

3, there is no user in the Projectrole "Developer"

In the next Case i will provide the Information you asked for. (atm i dont know the affected issue which makes it impossible to provide the information).

best regards,

[Nic Brough -Adaptavist-]

I don't understand.  I asked for a list of the post-functions for the issues that are being affected by this problem, and you gave me a list from somewhere totally different?

Could you please confirm if the screenshot is from an affected project/issue's workflow, or give us the screenshot from one that actually is affected?

[Lukas Payer]

The listet post functions above are from an workflow which is connected to an Project affected with this problem.

but now every issue in this project is affected.

[Nic Brough -Adaptavist-]

So 1 and 3 are in use in the affected project.  I'm confused as to why you said they are not if they are.

So, now that we know that they are in use, could you give us the symptoms from one of the broken issues as I described?

[Lukas Payer]

1 and 3 are not used in this project.

This Workflow is used in many projects, a few of them provide the criteria needed to trigger 1 and 3 (like user in projectrole developer and a filled user picker field).

The only thing i know -> the assignee on the dashboard is not the same assignee in issue.

For example, on my dashboard the assignee for abc-123 is Bruce but when i open the issue abc-123 the assignee is not Bruce but Alice.

[Nic Brough -Adaptavist-]

If 1 and 3 are not in use, then why are they in your post-function list?

Please, I need to know what the post-function list is in the project/issue type that is affected by this problem.

If it is the screenshot that you have given, then 1 and 3 are in use.  (And I'm very confused as to why you would keep saying they are not when they are)

[Lukas Payer]

1 and 3 are in the worklfow but cannot be used from all the projects because not all of our projects have Developers in the Projectroles neither do all of them have the Field "Owner".

So when i say "are not in use" i mean they cannot be used because the criteria to trigger the post function are not given.

For example, lets say we have 3 Projects. 1 of 3 Projects have Developers and the Field "Owner".

All 3 Projects use the same Workflow but 2 of them cannot trigger the Post Functions as they dont fill the criteria to use them.

Thats my understanding of how Jira Workflows works.

As far as i know all of the issue types are affected, but not every issue is.

The uploaded screenshot display the postfunctions of the Workflow from the affected projects.

[Nic Brough -Adaptavist-]

So, they are in use.  Thank you. 

The fact is the post-functions are there, so they are being run.   I am afraid your understanding of the workflows is wrong.  Post-functions are run.  What they're for and what they might do, and whether they have internal conditions, we shall probably return to.

So, now can we get a description of the break for one of the issues that is going wrong?  For example:

Assignee was Alice before transition, the transition should change it to Bob (the project lead), and that is what is in the index (search), but when we look at the issue, the assignee is Charlie.

[Lukas Payer]

Oh okay, thanks for explanation! :)

So Assignee was Alice before transition, the transition changed it to our Dispatcher User (which is correct because Alice assigned it to Dispatcher) and the Dispatcher User is correctly displayed in issue but not in the filter on the dashboard. On Dashboard the assignee is still Alice.

[Nic Brough -Adaptavist-]

Ok, great.  Next question is a bit of detail: How did "Alice assign it to Dispatcher"?

[Lukas Payer]

Hello,

today i've faced another issue but with an different Workflow and different Post Functions.

FYI In the search there is also the wrong assignee displayed.

I dont know how, Alice dont have the permission to assign Issues (like with the Button "Assign") and in Post Functions of Workflow there is no Function which assigns the issue to Dispatcher (or Bruce in this Case).

There is also no component configured in issue (nor component leaders in Project Configuration).

Do you know any other way to assign Issues?

[Nic Brough -Adaptavist-]

I suspect the problems are related, but I still need to know the behaviour in the first one.  How did "Alice assign it to Dispatcher"?

[Lukas Payer]

Hi,

i think i located the problem.

i want to correct my last comment -> there is an post function in use, it triggers an webhook which looks at the user picker field "owner" and sets the user in assignee.

till Jira Software v8.2.x it works fine, now with version 8.5.4 it looks like the indexes are not being refreshed after the run of webhook post function.

we will optimize the script behind the webhook.

best regards

[Aditi Jain]

Guys, 

Just to update, I've finally did background re-indexing, and it helped.

Results are back to the normal.

Thanks for all your inputs & suggestions. 

Thanks.

[Petr Papousek]

Good to hear :-) so the suggestion to reindex from Ollie Guan could be accepted as solution now I guess :-)

[Ollie Guan]

I'm glad you can solve this problem.

I have encountered a similar phenomenon before, and finally found out that it is caused by the sequence of steps of the postfunction in the workflow. Re-indexing finally solved this problem.

[Nic Brough -Adaptavist-]

Ok, that's great.

However, you now should look to see what is breaking your indexing.

A full re-index is "plastering over the cracks" - you should be looking to see what is causing it to break next.

[Aditi Jain]

Actually, that's the reason I was not doing re-indexing. But then it was already 3 days with no reasonable outcome, so finally opted this option.

Also, one more point to add here is that, I thought that this might have happened due to the fact that we have multiple admin users here and, multiple field level changes and even workflow changes are being done frequently, so that could be one of the reasons breaking the sync.

Anyway's since you have mentioned it now. Will keep my investigation on :)

Many Thanks.