I have found that the issue navigator is reporting a wrong status for an issue, i.e., the issue screen shows status A while Issue navigator shows B.
This seems to be caused when you use post-functions in a workflow. In my case I have a scriptrunner and a 3rdparty plugin.
After rebuilding the indexes for the instance, in one case the status is shown OK, but in another it does not change unless you edit the issue.
Is this a known bug? Fixes?
It's not a bug in the navigator - the navigator uses the index to read it's data from, whereas the issue view screen uses the database.
What's happened is your index is not being updated, so it's drifted away from the database.
The usual culprit is pretty much what you've guessed:
Your 3rd party plugin may be the culprit, or your script, but that's where the "bug" is.
A post function is updating data after the issue has been indexed (check the order of post functions on your transitions).
I double checked this and the reindex is always performed after any custom postfunction
Or, a post-function or listener needs to re-index the issue explicitly and is not doing it.
According to this KB , after Jira 5.1 indexing has changed for workflows transitions and plugins should not worry abou it. In particular I have a scriptrunner script that creates issues B from issue A, but issue A status is wrong in the Navigator after the transition for issue A workflow.
Yes, 5.1 improved it, so there's less need to explicitly re-index, but the symptoms you are seeing are very clear - it is not being done when it needs to be
You need to isolate which post-function is causing the problem and work out why it's not re-indexing.
I had not noticed this warning from the plugin site:
Due to indexing changes in JIRA 5.1, this post-function should be placed immediate after the function: Re-index an issue to keep indexes in sync with the database. If you don't do this, the parent issue will not be indexed correctly.
I'm having trouble with this same re-index issue in a JIRA 5.2.4 instance. My custom post-function is placed two steps above the default re-index post-function, and I've made sure that it throws no exceptions, but still the default re-index doesn't work. This is a screenshot of my list of post-functions for a specific transition; the custom post-function is circled in red:
What I still haven't got to understand is, in which way a custom post-function can disable or block a further execution of the explicit re-index function? Even the "update change history" function is executed correctly, so why only the re-index function is affected, unless the custom post-function is placed below it?
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!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG