|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Jon Gunnip - 14/May/05 11:40 AM
It would be nice to know what kins of workarounds are available to support such operations (e.g. write a custom report via a plugin)
Hi Jon,
You are absolutely right: creating a custom report is an option. More information about writing a custom report can be found here: This issue has been open before plugins appeared in JIRA, and unfortunately we did not add this suggestion here. Thanks for the note. Thanks, This feature is very valuable. A 'not' checkbox before the filters would solve it, and in the cases of listboxes a 'none' option just line the 'all' option would go partway towards solving the problem. Not having this is a big hinderance, since it makes issues where a certain tag has not been filled out (say it used to be not required but is now required) difficult, and hence prevents block operations.
Being able to search for a list of known KEYS in either the quick search or the Find Issues area is a highly requested feature.
I'd like to see this feature too. I have got a use case where a certain person wants to get a list of all issues that do not have a custom id (=testcase reference assigned). A simple "NOT" checkbox would do the trick. Although more sophisticated filters would be a really good enhancement. I think filters/search a re the most used feature in JIRA.
My request, JIRA-8781, was marked as a duplicate of this.
My request was to simply allow using the NOT operator as a unary operator in a text field. That is,
Hi!
A simple NOT checkbox would be sufficient for us as well Using JIRA 3.5.2 here and the Text Search does not seem to do any exclusion for me. i.e. The docs give the examples:
"atlassian jira" NOT "japan" "atlassian jira" -japan But the exclusion filter does not seem to do anything. Are the docs out-of-sync with the current features? I would like the filter to also be able to handle NULL in searches. A filter were all due_date is null.
Kevin,
Are you trying to run the query on this instance of jira? If so, what is the issue that should not be returned in the results due to the exclusion? Thanks, As mentioned above, it would be very nice to have a NOT option for versions, developers, or any type of list. Perhaps 2 lists wolud be more appropriate so we could be extremely specific...
Fix For: a list box, we select the versions we want to see in the query (as it exists currently) At any rate, better support for logical operations on static fields would be nice. Please please please give me a "NOT" operator on any field in a filter - inlcuding Custom fields.
Comparisons would also be nice. "where priority is greater than normal", "where due_date < 1week" would be nice.
Having an OR condition on filters would also be helpful. In my case I have several custom user fields and would like to perform a search on all issues in which a person has been assigned a role (e.g. Assignee OR Evaluator OR Reporter = <Current User>). I could then create a dashboard portlet using this filter (e.g. similar to the 'Assigned to Me' portlet).
Stephen - while it doesn't get you what you need, the Participants
 field comes close:
Options such as AND, OR, NOT, NULL would all be very useful. I would even be happy with a partial implementation, where such options could only be set programmatically (such as from a custom portlet or project page). In that case, the user could only start a new filter rather than editing the "extended" one.
Would that make it easier to get a feature like this on the roadmap? I can see that a user interface to allow all of these possibilities might be almost impossible to figure out. Actually, I would go for an "advanced" function that would let me put in the "where" portion of the SQL query and be able to save that in a filter. I have been playing with some direct queries for things that do not have a user interface. I recognize that some of those queries could get complex, so documentation would have to be beefed up.
That's exactly what one of JIRA's competitors offers: a SQL Query like window where you build queries on the fly without having to know the database schema.
Actually, direct SQL wll add yet another benefit, namely logical fields (that appear in query only, not in database) - but that a completely separate issue (e.g. I always wanted a column with the value of (Status+"\n"+Resolution), which saves place in the query width...))
I agree that having a way to create moderately complex sql queries as filters would be a huge benefit. I personally believe that this could be implemented in a way that takes some reading of docs and or understanding of SQL to use, since there is already a very simple interface for building simple filters.
I'd like the ability to search for all issues where MultiSelect Custom Field = null (because this custom field isn't required to have a value), but I don't have that choice. I'm basically looking for something equivalent to Fix For = "No Fix Version", Component = "No Component", and Affects Version = "No Version". It looks like the pre-made multi-select fields have a null concept for searching on, but custom fields do not.
I have various selection fields like the "Fix on" and "Component" and numerous custom lists that I'd like to have the capability to set the filter for "NOT" semantics.
Right now you have to create "all but this one" filters and then have to remember to update them when you add another to the list which is a right pain. (copying some of my previous comment from 12259)
Use case: A manager, team lead, etc. needs to find "all tickets that relate to a version". We'll call it Version 1.0. Usability: "OR" searches are sometimes represented in other apps by the metaphor of "stacking" or "joining" searches. Ex. Create Filter A, then create Filter B, then create a filter that is the result of A and B. You could, near the top of the "new filter" UI, give a link "Create combined filter" that takes the user to a simple UI where N number of listboxes are presented each filled with the list of currently-saved filters (and of course the predefined ones too.) I agree with the idea of building complex filters by composing one or more simpler filters. We have approaching 50 shared filters, most of which are variations on a handful of themes. Please vote for JRA-6527 if you'd like this feature.
Agree that NOT/AND/OR would be very useful to us in building filters and on the fly searches for our projects.
Also really important to be able to search/filter on fields being less than or greater than a certain value (e.g. estimate > 100 hours) - not sure if this should be entered as a separate issue. Is this on any kind of product calendar to get added in an upcoming version?
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Improvement
Open
Major
Better support for logical operation (and/or/not) type of filters.
