|
[
Permalink
| « Hide
]
Jon Gunnip added a comment - 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?
We would like to add my wholehearted support for this enhancement request!
Our users are extremely frustrated by the lack of ability to do logical searches and 'not operations'. For example, they would like JIRA to have additional option in drop-down menus - "Any User except..." , e.g. 1. Filter bugs reported by Any User except John Smith. Are all the options you are discussing above going to cover the above request? And yes, can you please mention when this is targetted. I would also like to see the priority increased from Minor to Major. Thanks for listening. I received a support request - JSP-12851
- for more advanced search options, specifically around 'negative' criteria. For example, the ability to setup a filter where 'fix version' is X and 'affects version' is NOT Y.
Ideally something like the feature from Trac where you can basically write your own SQL to generate filters. The customer has already voted for this issue, however I encouraged him to add a comment. Cheers, As requested by Ian in the previous comment, here's one from me...
Here's a scenario. We only use 'versions' for actual released versions, not every internal build. Therefore If we spot a bug on an internal build and fix it before that a later build for the same external version is released, the 'affects version' and 'fix version' is the same. To create a change report for public release X, I want to create a filter which shows me all issues fixed in X, unless the affects version was also X. This requires a 'not' style filter attribute. Another VERY common scenario is the ability to search for issues where status (or resolution) is NOT 'x'. Currently, you have to highlight every other value, except for 'x'. And in our installation of JIRA, this is very many.
Below are some examples of the type of searches we need to do in JIRA but which are not currently possible:
1. bugs where Reporter or Assignee in User X , Y or Z (without the need to put just them into a group) Seems to me this is a major issue, not a minor
 What is going on here? This is the 6th most popular issue in the whole JIRA project and it's getting no attention from Atlassian, as far as I can tell.
There isn't even a fix version planned. What's it gonna take? Ray is absolutely right; this should be major. I am not sure how to get the priority raised. Seems minor issues do not get addressed even though they may be the 6th most popular and the request was opened on Apr 03.
You would think that 4 years would have given them enough time to work it in to one of the releases. Like the rest of you, Polycom is really eager to see this changed !! We had occassion to discuss this with Atlassian and their stance is that they hear us. They do know important this change is for the users, it's just not easy for a host of reasons. For any customers in the Bay Area, there's an Atlassian User Group mtg next Thursday , June 28th, 1-5PM at Stanford. Consider attending to get your voices heard and discuss workarounds with other customers. Here's the link: I know you want to do the best solution for everyone, but that's hard and it takes a long time. Here is a suggested list of mostly independent changes that could be made that would go a long way to satisfying many of the issues linked to this one. All of these are on "find issues".
Does it satisfy everyone? Nope. But it will go a long way to making our jobs easier. Reid, can't agree you any more.
We used Devtrack before, it has powerful search function, supports "And", "OR", "Not" and parentheses. I was thinking to enhance JIRA to have same function, but seems too hard, after thinking, I believe "Not" function can support most of our requirements, others can be done by running search multiple times. Hi,
I have raised the priority to major to reflect that we do believe that it is very important. Unfortunately, it does not make it any easier to implement. A lot of complexity comes from designing an intuitive UI that will allow to make a query and validating the input. As Custom Fields in JIRA are very flexible, they do make this feature much harder to implement. At the moment, I do not have a date of implementation for this feature, but I asure you, we are aware that this feature would be a great addition to JIRA. Cheers, We have custom fields of type "user". One is Tester, which we wish was a first class field.
Currently we have to create a dummy user ("... unassigned tester") so we can find tickets not assigned to a tester and assign them. So Reid's comment is right, but lets be sure this works for all fields of type user. I agree that if we got NOT we would be well on our way, and I think we could revisit the OR issue later which results in a significant UI redesign. (At that point, we'd want a sort of "query builder", where you would have a pane showing you the query to date, like in manage-filter's query summary, and you would have some selector which would help you operate on pieces of the query, contribute to them, move them around, and could do so in a OR or an AND context, etc. But I think that could be a follow on issue for sure.) Anton: PLEASE consider breaking this "epic" into smaller stories that can be implemented in pieces. Specifically, a simple "NOT" checkbox on a subset of the fields in the current filter builder would give a HUGE amount of value n the near term. Holding up this simple improvement while trying to come up with the "all new, all singning, all dancing feature that does everything" is the antithesis of the Agile approach and seriously undermines the ability of JIRA to deliver incremental ROI to both customers and to Atlassian.
Hi,
You are absolutely right, and when we attack this feature it would have to be in stages. To be honest, some of the work on making this possible is being done. For example, in JIRA 3.5 a lot of searching code has been refactored from the Issue Navigator and into separate "searcher" objects (this work also allowed for cross project searching and issue types per project to be implemented). In JIRA 3.7 the Issue Navigator views have been refactored out of its code and into plugins. We are trying to simplify the whole search infrastructure to flexible searching possible to build. The main issue is that there are quite a few issues that are very popular but are not straight forward to implement without compromising the stability of the product: Cheers, How about adding the concept of "runtime variables?" One could define a variable in the individual queries that would only need to be changed once in the whole stack, like:
query 1) where Fixed-In version = var X If I then need to change X (which might be very frequent,) **I would only need to do it in the stacked query settings, not in both queries 1 & 2. ** In fact, it could be a runtime selection on the query result screen itself, to save the user from having to go through an Edit path to change it. So I call my query "Related to Specific Version" and run it; and the result screen has a widget to pick the version. I agree with most of what is being said here and need to add my two cents.
We have a custom Workflow set up that uses and "Acceptance" field after the bug is closed for the customer to accept the bug as being fixed according to the bug or reject it. When this field is created JIRA added "none" as an option in the pull down menu, along with my two values, "accept" and "not accepted" and I default to "none". This makes it so that those not given permission in the roles to use this field will not see it show up on the summary sceen of the bug. (thus avoiding confussion for those projects that do not use this feature. The problem is the same as that mentioned above. My customers need to run a fitler to report ONLY those bugs that have none in this field so they can test and approve. And JIRA provides no way to do this. They use none in the custom field and then allow no way to search on it. My main gripe here is that every other tool I have ever used to track bugs gives you the option to NOT a search or in some other way to get around this. JIRA does not and from the looks of the threads on this issue is REALLY dragging there feet on getting this fixed. Excuses for not getting this emplemented do not cut it in my book. It looks like this issue has been popping up in different bugs reports for more that a year and still the only solution is a workaround. IF NOTHING ELSE iMPLEMENT THE "NOT" FUNCTIONALITY SO THAT THOSE OF US "TRYING TO USE" JIRA CAN KEEP UPPER MANAGMENT HAPPY. AND ALLOW US TO KEEP USING AN OTHERWISE GREAT PRODUCT. For what it is worth not having this feature was a major factor for not renewing our enterprise license. I'll start believing that Atlassian think it is important the day they'll publish a proposal and commit to a JIRA release.
I'm actually not looking for a new feature in what I'm trying to do (though I REALLY want a NOT - even if it's just a checkbox to start with). What I really want right now is for the existing documented functionality to work. As Kevin Teague commented over a year and a half ago:
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 cannot get this to work for me either. If I could at least have this documented functionality working properly I could limp along until new features come along. Another "not" related feature request:
We need to be able to search for issues that do not have "original estimate" specified. There is a distinction between specifying a "zero" value and not specifying any value. We need to be able to look for issues where the "original estimate" was never specified. Why is this feature so difficult to address? Is the GUI the problem?
If so, why don't you implement the low-level support and let the expert users to extend the filter by manipulating the XML (generated by the filter "wizard" and stored in the SEARCHREQUEST.REQCONENT field) directly via SQL commands? Please, provide us a workaround! We are definitely interested in this feature, and as many have mentioned above, it is documented that "NOT" operation works, however when we try it, it fails to return the correct query. Do you have any tentative eta as to when this functionality can be expected?
This is a huge issue for use. The ability to have AND, OR, NOT, NULL in our fliters is a necessary for our business needs. Is this scheduled for 4.0?
Just so you're aware – my organization today started investigating Bugzilla as a JIRA replacement. This was the #1 deficiency that prompted the move.
I agree that this should be in JIRA. We use JIRA Client
as a workaround. It has support for creating the complex filters. Bugzilla as a JIRA replacement? Good luck in your comparison. There are shortcomings in JIRA but Bugzilla is not even in the same ballpark as JIRA with regards to features. Just my 2 Cents.
We moved away from Bugzilla to JIRA because of the severe limitations in Bugzilla. We use the JIRA Client as a workaround as well, but it sucks to have to have two tools, and only a few of us have coughed up the $$ for the win32 client.
btw, we also moved away from other solutions (TestTrackPro and DevTrack). I help maintain the Jira instance for Varolii Product Development, and this I have received several requests for this capability as well. We recently moved from Bugzilla to Jira. I am sure that this very search could indeed have been accomplished using Bugzilla.
Filtering has to be one of the most disappointing things in Jira. I can't believe I can't filter on some text not being in a field. Please fix this.
Gary Barnes commented on JRA-1560: Filtering has to be one of the most disappointing things in Jira. I can't believe I can't filter on some text not being in a field. Please fix this. – It would be nice to have an "advanced" quick search that let's you run run lucene queries using the QueryParser, then I could just run queries such as: "+issue_assignee:(echlinj OR someother) +(projid:10000) or -issue_assignee:(echlinj) (to get everyone else's issues.
I can see that the UI for the filter build couldn't handle this at the moment, and that you have a bunch of special handlers already for quick search, hence some sort of Advanced Quick Search would be nice. And it would be nice to be able to view the raw query for existing queries (without looking at the logs), such that you can easily modify it... this really should have been in the first version...
http://almworks.com/jiraclient/screenslide.html?name=queryBuilder looks like somebody has beat you to it! That's odd, someone else adding such important and useful features to your product while it has been sitting here for years. Look at that screen, I could build that and make it work within at most 2 - 4 weeks, why so long?? This is absolutely important to us. I get questions about it all the time. We have had to resort to giving some people JIRA database read permissions and posting some SQL snippets to our wiki. Most simple example:
We have a custom field that links to another system and is called "Helpdesk Ticket". I want to get a list of all open JIRA issues that have a value in this field, indicating that they exist in the other system. In the meantime I did this right against the database: SELECT ji.pkey, it.pname AS issuetype, cfv.stringvalue AS HelpdeskNumber, John
You are not alone in your approach. We've ended up writing scores of While some of this is acceptable given the complexity of the report/ Sent from my iPhone On Jul 3, 2008, at 12:35, "John Price (JIRA)" <jira@atlassian.com> See issue JRA-15196.
Portlet works wrong because of lack of said functionality. In our pilot project of JIRA, the need for powerful searching as documented by this issue record became the top concern, enough so that it could sink the pilot. Need a date when this will get fixed!
By the way, we are using Serena's "PVCS Tracker" and have been for a decade or more. This tool had boolen based searching from day 1 of the tool, so I cannot understand the lack of this feature in JIRA. One could even introduce more complexity by the use of parenthese. Please fix this as soon as possible! Voted for this issue - Our needs are simple, yet unsupported I can tell. We just want our filters to show all issues with bla bla criteria that are ANY status except closed. As it stands now, when we add new statuses, I have to go update our public/private filters to include those new statuses.
I just want to be able to select (not) Closed status and I'd be done forever. Thanks! Hallelujah! I see that today this feature was finally scheduled for v4.0 today. Now the question is when will 4.0 be shipped! This has to be the most significant new feature in Jira since 1.0. I was really nervous about recommending Jira in my new company after living w/o this feature in my last company.
Please be sure to to allow nested And / Or and Not queries so that I can do things like ((A or B) AND (C or D)) OR E - if you do this without nesting the Boolean logic, we will just be back to square 1. Lets get this right in 4.0. Hi Chris,
We definitely intend to get this right. I'm afraid I can't give you a ship date for 4.0 at this stage, however I can assure you we are very excited to be working on this popular feature. Regards, Chris Mountford Yes! I agree with Chris, this should be a design where the user can take very simple queries and "layer" or "stack" or "nest" them. It should be infinitely extendable, limited only by processing power. Please, please, please, do NOT go in the direction of making *one* single query interface that is even more complicated than the current one. It should be a simple/repeatable action: query && (query || query) ... etc....
Thanks John for the support, but I'm wary that we should force the user to nest queries in order to do basic boolean logic. e.g. Rally has a nice simple single screen UI for setting up complex queries with all of the boolean logic you could dream of. I'd be bummed if Jira 4 forced people to create multiple queries (and deal with many screens) just to that.
For UI design, I used one issue tracking tool called Devtrack before, it has great logical operation support, you may take a look.
Great news !
Another source of inspiration could be www.blist.com. Try a look and play with "Lenses" (queries). They have found a quite easily way of displaying (and creating) queries (especially when using AND, OR....). Hello,
As mentioned earlier - we are really happy to be able to bring this functionality into the product. The approach we are taking to solve all the scenarios described within this issue is to produce a JIRA query language. This will allow for a large amount of flexibility to meet your needs without an complex UI getting in the way. I will share more details in the future with everyone - ship dates, query syntax, sample queries, are still being discussed. Cheers. Brian Lane I sincerely hope there will be a GUI to wrap the query language - none of our users (programmers or executives) will be want to remember a query syntax as well as field names and valid search criteria. I know you will share more information later, but a properly design GUI will not get in the way - rather it will enabled customers to use it without being programmers.
I very much second that.
It would be helpful to have the full power of regular expression here. I had several issues where I was searching for workarounds because I couldn't state a simple search pattern because it's not supported. Would it be also possible to ad a filter capabilities for issues with a remaining estimate >0?
more in general would it be possible to filter for all issue fields? thanks, Salutations,
Same comments with the others. Thanks and God bless. Searchin on assignee should get more powerful search features.......This feature is veerymuch required. When some modules are assigned to various users it should be possible to get all the modules with single filter to better track the module development, for ex.. There are many requirements like this... It becomes tedious when only one issue can be searched per filter.
Best Regards, Hi, being able to search where a "custom field value" is "NULL" is great.
Am not sure if that would be context based, or screen/field configuration based, but if this has a risk to put lots of strain on the system, then how about having a "toggle" switch, for the jira-administrators to click (in real time). Eg, if we add a new field to a form, and wish to now populate that field in previous issues, we might want to search for issues matching a particular criteria, where that field is null. We could simply go in as administrator, enable the NULL searching feature (similarly to the API toggle link), run the NULL search and turn it off again. regards, I vote for this feature too. An important feature for us is a GROUP BY function in conjunction with SORT ON. For example, we would like to say find all issues based on some query, sort on the priority, and group by component. Then you get a list back grouped by each different component, and within each component group the issues are sorted on their priorities.
I voted too.
for example(V3.13): there are issues summary(5 issues) ----------- test1 ok test2 ok test3 ng pickme yes ------------ when I input test in "Text Search" of "FIND ISSUE", it works(find first 3 issues). input test NOT "ok" or test -"ok", it works too(find the third issue). but when I input NOT "ok" or -"ok"_, it returns no results. I notice that help says "The NOT operator cannot be used with just one term." but i need set conditions to search both the 4th and 5th issue. I voted for the issue ,too.
I would like to get a report that shows me e.g. all issues that are assigned to me but where I am not the reporter. Thanks, Janine I'd like the ability to search on a "set"field - i.e. the field has any value at all for a customers field
i.e. all issues reported by ANY customers So I am not sure that my scenario is well covered by the existing discussion, I want to be able to do set operations on results of filters.
So if filter A results in issues (1,2,3,4) and filter B results in issues (3,4,5,6) and filter C results in issues (2,4,7,8) Union A,B,C = (1,2,3,4,5,6,7,8) This would allow me to build very disparate queries and build sophisticated reports from them. Why is this useful? We have very heavy reporting requirements for our product. For every issue we DO NOT implement, we need to show that we have a justification for that decision. All Issues that have never been resolved, and effect Version X In addition we have a set of issues that are scheduled for fix in this version, but are not yet resolved, so I would like to take those out of the list. Hasan,
It looks like Atlassian is making a major overhaul of the querying ability in version 4.0, You may also be interested in JRA-6527 We struggle with the reporting ability in Jira. There is so much information stored in Jira that we would like to report on, but it's not possible with the filters.
One group created their own reporting useing Putty and another group is using Crystal Reports. Jira is a company wide tool and it doesn't make sense for each group to use thier own method of reporting. Reports can't be shared across groups because they can't be easily ran in Jira. Crystal Reports is the closest we've used to a good reporting tool for Jira, but you must understand all of the database tables and SQL. This is not in the 'normal' skillset of a Jira user. A UI for more complex reporting is absolutely necessary for Jira. I wouldn't try to make the UI simple and ignore the need for complex reporting. Jira is a complex tool and in order to report on all data the UI will need to be sophisticated. It would be helpful to include some sample reports that can be used as a guide for the users who will be creating reports. Anyway, I can't wait to have a better/easier way of reporting on Jira data. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
Better support for logical operation (and/or/not) type of filters.
