Hi, I've got a problem affecting the search results of a query involving the greater than operator, Releases and the affectedVersion Field. But it's inconsistent, the issue doesn't seem to appear for all users in our Jira Cloud instance.
filter = 10135 and issuetype = bug and status != Done and affectedVersion >= xxx-7.6.5
Filter 101035:
project = yyy and component in ("Comp1", "Comp2", "Comp3", "Comp4", "Comp5", "Comp6", "Comp7", "Comp8", "Comp9")
IRL order of versions on the Releases page:
xxx-7.6.19
xxx-7.6.18
xxx-7.6.17
xxx-7.6.16
xxx-7.6.15
xxx-7.6.14
xxx-7.6.13
xxx-7.6.10
xxx-7.6.5
Results for User1
Issue Type | Key | Affects version
Bug | yyy-1661 | xxx-7.6.16
Bug | yyy-1570 | xxx-7.6.16
Bug | yyy-1522 | xxx-7.6.16
Bug | yyy-1372 | xxx-7.6.16
Bug | yyy-1361 | xxx-7.6.16
Bug | yyy-1351 | xxx-7.6.16
Bug | yyy-1350 | xxx-7.6.16, xxx-7.6.18, xxx-7.6.19
Bug | yyy-1349 | xxx-7.6.16
Bug | yyy-1348 | xxx-7.6.16
Bug | yyy-1346 | xxx-7.6.16
Bug | yyy-1247 | xxx-7.6.16
Bug | yyy-1236 | xxx-7.6.16
Bug | yyy-1212 | xxx-7.6.16
Bug | yyy-1132 | xxx-7.6.5
Bug | yyy-733 | xxx-7.6.13
Results for User2
Issue Type | Key | Affects versions
Bug | yyy-1350 | xxx-7.6.16, xxx-7.6.18, xxx-7.6.19
Bug | yyy-1132 | xxx-7.6.5
User2 is missing a lot of search hits.
The query consists of four parts:
filter = 10135
issuetype = bug
status != Done
affectedVersion >= xxx-7.6.5
I then had both users run the query four times, each time with one of the four parts removed:
issuetype = bug and status != Done and affectedVersion >= xxx-7.6.5
filter = 10135 and status != Done and affectedVersion >= xxx-7.6.5
filter = 10135 and issuetype = bug and affectedVersion >= xxx-7.6.5
filter = 10135 and issuetype = bug and status != Done
The results for the two users differed every time except for the last one where affectedVersion >= xxx-7.6.5 was removed, that attempt yielded the same search results for both users. Hence my conclusion that the problem involves the operator, Releases or the affectedVersion Field.
When User2 "spelled out" the versions in the query rather than using >= xxx-7.6.5 he got the same results as User1 (who used >= xxx-7.6.5, see above):
filter = 10135 and issuetype = bug and status != Done and affectedVersion in (xxx-7.6.5, xxx-7.6.10, xxx-7.6.13, xxx-7.6.14, xxx-7.6.15, xxx-7.6.16, xxx-7.6.17, xxx-7.6.18, xxx-7.6.19)
I continued by trying a range of queries on both users, playing around with the operator and versions and User2 sometimes got incorrect results such as:
filter = 10135 and issuetype = bug and status != Done and affectedVersion < xxx-7.6.5
yielding a bunch of search hits with affectedVersion higher than xxx-7.6.5 (whereas User1 got zero search hits, which is correct).
User2 tried a couple of things to work around the issue: logging out and back in to Jira, clearing browser cache, trying different browsers (Chrome and Edge, both on Windows 10), none of it worked.
But when User1 and User2 logged in to Jira on each other's computers the issue remained for User2 and for User1 it still worked as expected, so perhaps it's got something to do with some user settings?
Would really appreciate some help with this. As it stands right now we can't trust the data we want to present to managers and other stakeholders.
Br
Martin K
Hi @Martin Karlsson , Since the issue persists for User2 regardless of the machine used, it might be related to user-specific settings or permissions. Ensure that both users have the same permissions and settings in Jira.
I'm also wondering if other users have the same search results as User 2, could you check as well with other users to see if they can see the same results as User 1 (the expected results)?
Moreover, can you also try to run the query with version ID instead of the name?
Might also be worth checking if Filter 101035 is shared with user 2 and can run it and see the filter search results.
To the best of my knowledge User1 and User2 are identical. They were created at the same time with the same rights, groups etc. Do you know any particular settings that could affect this? Language and timezone are the same.
We since discovered others that were affected by this problem and yet others that weren't, these users have a slightly different set of permissions etc than User1 and User2.
The filter is shared with everyone.
When User1 and User2 tried the query with the version ID today it worked for both but the thing is that the query now works for User2 with the name as well. I e the problem has disappeared and the reason is beyond me, no one has to my knowledge changed anything about our setup, permissions for users or anything else. It just started working for no apparent reason. I've asked other affected users to run several queries that previously failed and now they all get same results as the users who weren't affected by the issue.
Sorry about the late reply, I wanted to verify this for all affected users before getting back to you.
Good that the problem is gone but I'd like to know what caused it. Afraid it could pop up anytime again.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Martin Karlsson , It's strange indeed that it's just started to work for the affected users without any changes, however, it's recommended to rely on the version ID instead of the name in JQL as I can see in this guide here.
My assumption is that it could've been temporary behavior due to any recent incidents. I'd recommend monitoring this closely. If the issue is encountered again, record it and raise a support ticket for the team to check this on your site directly.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I will keep my eyes peeled and for sure raise a ticket if it occurs again, thanks for the advice 👍
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Something else (which does not fix the issue between the two users):
In Jira JQL you can search issues by fixVersion pretty easily:
fixVersion=v2.2
or if you’re interested in more than one version:
fixVersion in (v2.2, v2.4)
You can even find issues matching a range of versions. For example, if there are 4 versions v1.0, v2.0, v2.1, v2.2, v3.0 and you want to see all v2 versions:
fixVersion>=v2.0 and fixversion <=v2.2
It’s important to understand that the order of versions is controlled by the order they are arranged in your project’s versions configuration and not by the version number! If the order is incorrect, just go to your Project Settings → Versions and reorder the versions by drag and drop.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, I'm aware of this.
If the order is incorrect, just go to your Project Settings → Versions and reorder the versions by drag and drop.
I don't have Versions in my project's settings, but the drag and drop thing I can do on the Releases page. I posted the order my versions are set in since it matters for the operator I used.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Martin Karlsson ,
I've not seen this before, but the first thing that comes to mind is indeed a user settings. Do User1 and User2 have the same Language and Timezone (https://id.atlassian.com/manage-profile/account-preferences)?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Rudy,
Thanks for the quick reply!
Yes, both have English (US) as language and time zone Europe/Stockholm.
/m
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.