Created attachment 8345689 [details] [diff] [review] report-v1.patch (from the brc bug report) Description of problem: when doing a tabular report, i may get something like the following when specifying the whiteboard column: a 5 a b 3 a,b 4 b 2 when clicking any of the links in the report, the generated query uses the format of "contains a', instead of 'equal a' this means i will get results for both 'a', 'a b', 'a,b' in the generated report. also, if i chose the 'a,b' link, i will get all results, since they all contain either 'a' or 'b'. Version-Release number of selected component (if applicable): version 4.2.5-7.1 How reproducible: 100% please change generated query to use 'equals' rather than 'contains'. better if can also be case sensitive, since the tabular report is case sensitive to 'a' and 'A', but there is no way to make a report for equals (case sensitive), only for contains, which misses the point. Thanks, Itamar
There are two ways to solve this. I've done the one involving the least amount of change, but I'm not entirely convinced it is the right way of going about this. The alternate approach is to change all the queries in the report page to use the 'Custom Search' feature. e.g. f1=status_whiteboard&o1=equals&v1=... If you would prefer me to take this approach, let me know, and I do a new patch. The advantage of the second approach is that it works better with the 'Edit search' link.
Let's resummarize to better describe what the problem is. Tabular reports do not use "contains", they use "anyexact", which means that strings are split on commas by default. If your string has no comma, then this is not an issue as it will work the same way as "equals", making this issue much less problematic.
Severity: normal → minor
Summary: Tabular report links should open sub reports with 'equal to' rather than 'contains' → Strings are split on commas by default, making some links in tabular reports return an incorrect buglist
Comment on attachment 8345689 [details] [diff] [review] report-v1.patch >=== modified file 'template/en/default/search/form.html.tmpl' > [% query_types = [ >+ "equals", >+ "notequals", >- qtypes => ['allwords', 'anywords', 'nowords', 'regexp', 'notregexp'] } >+ qtypes => ['equals', 'notequals', 'allwords', 'anywords', 'nowords', 'regexp', 'notregexp'] } Your patch looks good, but why these changes in this template? To me, this is a different issue/RFE as adding new operators in the Search form has nothing to do with making links in tabular reports work correctly. One may agree to fix the links while he disagrees with having these two new operators available for whiteboards.
(In reply to Frédéric Buclin from comment #3) > Your patch looks good, but why these changes in this template? To me, this > is a different issue/RFE as adding new operators in the Search form has > nothing to do with making links in tabular reports work correctly. One may > agree to fix the links while he disagrees with having these two new > operators available for whiteboards. Adding the equals option was so that a user could use the 'Edit search' link in buglist.cgi and still have the same results. The more I think about it though, I'm thinking the second option (using the custom search fields for the searches) is a better option. Will do a new patch using that method later today. -- simon
Created attachment 8346938 [details] [diff] [review] report-v2.patch
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 926117
Comment on attachment 8346938 [details] [diff] [review] report-v2.patch Please re-attach your patch in the other bug. Your description of the problem in comment 0 is inaccurate and confusing (contains vs anyexact). And your bug is newer than the other one.
You need to log in before you can comment on or make changes to this bug.