When doing a simple JIRA query, I want to find all the bugs that are only attributed to one specific component. But when I use EQUALS, it returns results that are IN.
For example, when the search string is "Project = X AND component = Component_1 AND status = sx ..." I get the bugs that are associated with Component_1 and other components. This is acting like the IN function.
What I want is bugs that are associated only with Component_1
Mmm, that's a pretty obscure query - it's not often people would ask for "only that component". Why are things with that component AND other components not important? Surely if component X is breaking system Y, you want the people who own it to fix it for Y as well as X?
Also, you say "... and X and y and z..." is acting like an IN function. That's wrong, try it again, it's not an "in"
Anyway, because it's an unusual question to ask, I don't think it's available directly. I think your best bet for "only component_1" is going to be "component = component_1 and component NOT IN (component_2, component_3, etc". I don't think it's a particularly useful query for your humans, because they really won't care whether it's only got one component, but that's the best I think you can do.
It's not that obscure. We have Story tickets which we list all of the components needed to implement, some of which haven't been spec'd down to the specific implementation details.
If we have resources available to work on a specific component, sometimes we want to know which items we can work on. i.e. UserA only works on component B, so we want to list all open issues that are only component B, and don't rely on any other components.
Similar problem over here.
Our scenario: we have a team which works on a pretty separate component. We do have tickets, which involve this component among other components. There are fine, our product managers do want to see them. But that team also uses that very jira instance and project for tickets, which only affect that single team/component and nothing else. THOSE tickets are only confusing for our product managers and I would like to define a quick filter for the agile board in order to sort them out.
So I want to filter out all tickets, which have ONLY that component and NO OTHER component. Sure, I could proceed as Nic pointed out, but I would have to edit that filter every time a new component comes along.
Something like this would be good
component != "MyComponent" AND NOT component in (NOT "MyComponent")
but (NOT "MyComponent") is not correct JQL.
Ah, I have a trick for that one.
If you have the script runner addon, or can write an addon, you can write a new derived field (field with data built from other data on an issue). If that field is a simple number field of "component_count", then you can filter for "Component = myComponent and component_count = 1"
Billiant news. I do have Jamie Echlin's script runner plugin installed (big fan of it). But so far, I haven't created a scripted field yet. I did now but don't know what to put into the inline script field. I'm not familiar with groovy syntax. Can I bother you to paste the appropriate code here? ahem. ;-)
Searcher: Number Searcher
Template: Number Field
Inline script: return issue?.componentObjects?.size() as Double
And in the screen, the preview test looks great: I entered the issuekey of a ticket with 3 components and that preview ideed returned "3". Almost there!
But JQL behaves odd:
when I start typing "ComponentCount" (that's what I've called that field), the autocompletion suggests "~", "!~", "is not" and "is". It does not suggest "=" or "<" and such numeric operators. And when I write "ComponentCount = 3", I don't get an error message (which I would expect after those auto completion suggestions), but I simply get an empty result set. I expected to get at least that single issue, for which I've performed the preview test.
Same issue here.
We have a custom field which is multi-select called 'client'. The client field allows us to specify one or more clients that an issue impacts.
I need to be able to raise a report on issues that only impact a particular customer. We have hundreds of clients and the list evolves frequently, so it is not feasible to solve the problem based on 'labels in (X) and labels not in (Total - X)'.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events