Strikethrough although resolution value is <none>

[Stefan Jonsson]

Previously we had an issue with strikethrough on open issues. We solved that (after browsing through the various Q/A:s on this matter here on this site) by removing the manually added "unresolved" resolution and resetting the values back to none (very time-consuming...) and removing the possibility to edit the resolution by modifying the screens.

However, now I see strikethrough has reappeared on some of our open issues. 

Does anyone have any idea how this might have happened and how we can fix this? I'm puzzled. 

Please let me know if additional info is needed and I'll supply. 

[Mirek · Accepted solution]

Hi Stefan,

First of all could you try to run Integrity Checker and see if there are any issues?

https://confluence.atlassian.com/adminjiraserver071/using-the-database-integrity-checker-802592958.html

If there are can you fix them and check again?

Overall I think it is a problem with your workflow configuration. I do not see the whole picture of it but could you check if you are executing Issue Resolved event when setting up resolution that correctly set resolution date?

In order to fix all existing issues you would need to make a fake transition that is executed from the same status as target, put a post function to set resolution and use bulk change on all those issues (execute this transition).

[Stefan Jonsson]

@Mirek

Thanks for the tip. Didn't find it first since they had moved the checker. In Jira 7.10.0 it's found at System > Integrity Checker

I ran all the checks. "No errors were found."

[Mirek]

Good so the database is OK . Did you check your workflow?

[Stefan Jonsson]

Regarding the workflow setup, I already did the "fake transition", clearing the resolution as a post-function. That helped us in the first place and removed most of the strikethrough problems we had originally. 

Now, the resolution is NULL for all Issues that are not done. 

[Mirek]

Yes but do you fire Issue Resolved event and could you check if Resolution is not added on any other screen than where the issue is resolved.

[Stefan Jonsson]

@MirekThank you for your time.

Resolution is only added at the final transition Screen in our workflow. It's not on any other Screens. On all other transitions, I've added "clear resolution" as a post-function just to make sure no Issues have a resolution that shouldn't have a resolution. 

Searching for "resolution is not EMPTY AND status in(...)" where I list all statuses we use for Work-In-Progress Issues, I get "No issues were found to match your search" as expected. 

So I believe Workflows are correct. 

[Mirek]

@Stefan JonssonI stil want you to check the event that is triggered. Could you please check post functions and check what is executed when the resolution is set. Is it Issue resolved or maybe Generic Event (or something else.. )

[Stefan Jonsson]

@Mirek I checked post-functions for all transitions we have in the workflow and they all fire a Generic Event. 

Checked the history on one of the issues that we see this strikethrough behavior on and I see this:
1. Created

2. Updated the "Components field"

3. Changed "Assignee"

4. Changed "Fix version/s"

5. Changed "Assignee"

So this Issue has been in the "To Do" status ever since created. 

[Stefan Jonsson]

@MirekIt seems I have solved it now. Looking at the history (see my previous comment) I realized that this issue hadn't transitioned at all since being created. So I just transitioned the event to the next status in the workflow and then back again, and that seems to have fixed the issue! 

Thanks for your time and patience =)

[Mirek]

No problem. Glad that this is solved :)

[Lakshmi CH]

Thank you @Mirek for great solution.

It worked.

In order to fix all existing issues you would need to make a fake transition that is executed from the same status as target, put a post function to set resolution and use bulk change on all those issues (execute this transition).

[Matt Doar]

I suspect your workflow for that issue is not clearing the resolution when the issue is reopened. Global transitions also have to clear the resolution because they can be the path to a reopened status. Check the History tab of your issue very carefully. 

Another way this can happen is if someone Moved the issue to a new workflow and new status without clearing the resolution. Again, check the History tab

[Stefan Jonsson]

Thank you for your time but I solved it with guidance from Mirek (see that thread)

[Tarun Sapra]

Hello @Stefan Jonsson

Strikethrough only appears on an issue if the resolution is set and if the resolution "unresolved" then there shouldn't be any strike-through, could you please share screenshot of an view screen (issue view) of an issue which is strike-through but in open state and also please share the list of resolutions used in your system. If the issue doesn't have any resolution associated with it still you see an strike-through then it might be data corrupt issue, could you also try to re-index and check again.

[Stefan Jonsson]

@Tarun Sapra, 

Thank you for your quick reply.

After some more investigation, it seems the strikethrough only appears on the "Activity" feed, see image below. Looking at the strikethrough issues (e.g. "BEHAVIOWEB-299" in the image below) in the Backlog or the Kanban board they do not appear with a strikethrough. 

Will try re-indexing to see if that might help. 

[Stefan Jonsson]

@Tarun Sapra: Re-indexing didn't help. 

Any other suggestions that could help us remove this issue?

[Tarun Sapra]

Hello @Stefan Jonsson

It still seems to be an indexing issue, thus my suggesiton is to delete the index folder completely and restart the instance and that should do the trick.

Stop JIRA
Make a backup of the following directory and all its sub-directories:

$JIRA_HOME/caches/indexes
Remove that directory and all its sub-directories:

$JIRA_HOME/caches/indexes
(info) This will be rebuilt when JIRA is re-indexed

Start JIRA
Perform a locked/full re-index of JIRA

[Stefan Jonsson]

@Tarun Sapra

Thank you for helping out. Unfortunately, that didn't solve the problem either. The problem still persists.

Unless you (or anyone else?) have another suggestion, we'll leave it like this for now.