We have encountered a problem that looks like this.
We have JQL conditions on our Postfunction and Event Listner. They work in all cases except the one below.
When an Event Listner or Postfunction is executing on a Transition that has a Screen that sets a custom field. When our long hits = searchService.searchCount(user, parseResult.getQuery()); tries to check the condition it gets 0 even though the value is set.
In any other cases where the value is set before it works. But during these Transitions with screens then it seems like the searchService gets the old issue value.
We have tried many things but still struggeling with this.
Hi Rickard,
unfortunately, the short answer is: it cannot work. The reason is simple: JQL conditions are based on the Jira index, and the index is only updated later, asynchronously.
Even if you move the post-function to the bottom of the list, you might still be querying against a stale index.
Thanks David, that is what I concluded as well, but thought that it might be a way to do this.
I could simply spin off a thread that sleeps for a while but it is an “ugly” solution compared to a callback pattern.
I guess persisting the issue in the PF before search is also async so that is no guarantee of getting the correct index as well.
well, just hypothetically, you could perform the re-index ‘manually’ as a part of the value edit during the particular transition. If the custom field is custom-developed, this should be possible. Have you tried anything like this?
