My predecessor created a custom field called "change type" that is similar to the standard issuetype. The problem: When you query changetype, the results get split into two values.
See screenshot, note that "non-defect" appears twice. Oddly, if you click on either one, the associated list contains all "non-defect" issues - the sum of both reported values (292+3).
I recently re-indexed the database hoping that would help. It didn't. Any ideas?
Do you have multiple contexts defined for the custom field catering to different projects? In that case JIRA has no way to determine that the selected values are the same even though the text is the same.
The only way is to get rid of individual contexts and use a common context for all the projects.
Renjith, thank you - this appears to be the cause of the problem. There are two contexts - one for a single project, and one for everything else. I need to do some digging to find out why this was done...and whether I can fix it. Thanks again! -Jeff
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Seems like some faulty value got inserted in the database some how, probably second value might have an extra space in it, please check the database for same.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Vishwajeet, but I believe this cannot be the answer. The reason: Clicking either of the returned values (as described in the original post) returns a list of all "non-defect" issues (295 issues). If there was a faulty value, you would get two lists - one with 293 issues and one list with 2 issues. Or am I missing something obvious?
I'm leaning more toward a defect in the Issue Statistics Gadget...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
What I said might be wrong but it still worth checking, there has to be some anomly for two values to be shown. search function might be trimming the extra spaces and the report you are looking at may not.
What I am suggesting are just posibilities from my past experience your environment and issue can be different.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I agree that it is worth checking. For lack of a better method, I tried the query in different ways, including making sure that "non-defect" and "change type" were quoted to exclude preceding or trailing blanks. I also used the "=" rather than anything that could have returned approximated results. No luck.
Do you know of a way to check the database more thoroughly? Thanks again for the interest.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
What database backend you are running? use database browser to browse the data.
I am not sure if that will help try running integrity checker on database.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.