You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I created a filter for an array with some conditions:
"(issueFunction in issuesInEpics("status in (development)") OR "Epic Link" is EMPTY OR labels = spike OR issuetype = Bug) AND project = x ORDER BY priority, "Epic Link", Rank ASC"
Eventually, 44 submissions should appear, but one is skipped even though I know it meets the conditions. What can I do about this? Why is this and could it mean that there will be more situations like this? This is important to me because I make the Scrum board dependent on this.
Which condition is that?
If the issue obviously has the correct value, but simply doesn't show - it is likely your indexes are off since JQL is fully based around indexes - it sometimes happens due to any intermittent problems or perhaps the values are being stored without it being indexed (e.g. certain automations).
If you are on Server, you might simply re-index the project and see if the issue comes up. If you are on Data Center, neither project or foreground re-index is recommended (I think Atlassian was complaining about something and something) so you might want to do a full "locked" re-index (https://confluence.atlassian.com/adminjiraserver/search-indexing-938847710.html).
Aaaand once it's fully re-indexed the issue should show up.
You could also try to just edit the issue, remove the value, add it back in - this should also create indexes for it provided that indexing generally works, and isn't just broken and nothing is getting indexed.
Does the missing issue appear in the filter if you re-index the project?
If so, it means you have some automation somewhere that is not correctly re-indexing the issue after making a change.
Since you posted this in the "Adaptavist" topic I'm guessing it would be a groovy script that uses the IssueManager to create or update an issue in a scripted listener or in a scripted postfunction (after the indexing step) and doesn't have code to manually re-index the issue.