Closed
Bug 759999
Opened 12 years ago
Closed 12 years ago
Custom searching doesn't work as expected
Categories
(Bugzilla :: Query/Bug List, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 677757
People
(Reporter: mail, Unassigned)
Details
This search
https://landfill.bugzilla.org/bugzilla-4.2-branch/buglist.cgi?v4=rc5tv%40home.com&o5=changedto&f1=OP&order=Bug%20Number&o3=changedafter&list_id=51333&v3=2008-01-01&resolution=---&o2=changedbefore&f4=cc&v5=rc5tv%40home.com&query_format=advanced&f3=cc&o4=changedby&f2=cc&token=1338444164-7655190a2deaa768bf9bb2f31fbae334&f5=cc&f6=CP&v2=2008-02-01
should return all bugs where the CC: value was changed by rc5tv@home.com to rc5tv@home.com in January 2008. At least that is what I expect it to return since the custom search is wrapped in parenthesis.
However it is return all bugs where the CC: field was update in January 2008 AND the CC: values was updated by and to rc5tv@home.com at any time (for example bug 1)
generated sql:
SELECT bugs.bug_id AS bug_id,
bugs.bug_severity AS bug_severity,
bugs.priority AS priority,
bugs.bug_status AS bug_status,
bugs.resolution AS resolution,
map_product.name AS product,
map_component.name AS component,
map_assigned_to.login_name AS assigned_to,
bugs.short_desc AS short_desc,
bugs.delta_ts AS changeddate
FROM bugs
LEFT JOIN bug_group_map AS security_map
ON bugs.bug_id = security_map.bug_id
AND NOT ( security_map.group_id IN (12,14,13,21,16,17,7,3,6,15,4,5,2,1,10,18,19,20,8,9) )
LEFT JOIN cc AS security_cc
ON bugs.bug_id = security_cc.bug_id
AND security_cc.who = 8112
INNER JOIN products AS map_product
ON bugs.product_id = map_product.id
INNER JOIN components AS map_component
ON bugs.component_id = map_component.id
INNER JOIN profiles AS map_assigned_to
ON bugs.assigned_to = map_assigned_to.userid
LEFT JOIN bugs_activity AS act_19_1
ON bugs.bug_id = act_19_1.bug_id
AND act_19_1.fieldid = 19
AND act_19_1.bug_when <= '2008-02-01 00:00:00'
LEFT JOIN bugs_activity AS act_19_2
ON bugs.bug_id = act_19_2.bug_id
AND act_19_2.fieldid = 19
AND act_19_2.bug_when >= '2008-01-01 00:00:00'
LEFT JOIN bugs_activity AS act_19_3
ON bugs.bug_id = act_19_3.bug_id
AND act_19_3.fieldid = 19
AND act_19_3.who = 19
LEFT JOIN bugs_activity AS act_19_4
ON bugs.bug_id = act_19_4.bug_id
AND act_19_4.fieldid = 19
AND act_19_4.added = 'rc5tv@home.com'
WHERE bugs.creation_ts IS NOT NULL
AND (security_map.group_id IS NULL
OR (bugs.reporter_accessible = 1 AND bugs.reporter = 8112)
OR (bugs.cclist_accessible = 1 AND security_cc.who IS NOT NULL)
OR bugs.assigned_to = 8112 OR bugs.qa_contact = 8112)
AND bugs.resolution IN ('')
AND act_19_1.bug_when IS NOT NULL
AND act_19_2.bug_when IS NOT NULL
AND act_19_3.bug_when IS NOT NULL
AND act_19_4.bug_when IS NOT NULL
GROUP BY bugs.bug_id
ORDER BY bug_id
LIMIT 500
Comment 2•12 years ago
|
||
This is, perhaps surprisingly, the current intended behavior of Custom Search in 4.2--that all criteria are independent. This makes the behavior of search considerably more predictable as opposed to its previous "magic" behavior of sometimes blending criteria. It also makes all operators work, when often they did not before.
I had a plan for future versions of search to allow you to do criteria that explicitly depend on each other. For example, for this case the UI would look something like:
[ Change ] [ by ] [ is equal to ] [ rc5tv@home.com ]
[ date ] [ is less than ] [ 2008-02-01 ]
[ date ] [ is greater than or equal to ] [ 2008-01-01 ]
(The other options in the "Change" menu would be "Bug," "Attachment," and "Comment".)
Given my current availability, somebody else will have to implement that UI.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Comment 3•12 years ago
|
||
The first step toward implementing that UI would be to implement a backend that can handle criteria like that, and deciding on how the URL parameters should be structured (keeping in mind that short URL parameters are preferred and that it should be backwards-compatible with what is there now). I'd really appreciate somebody working on this, although it would certainly be a fair bit of work (at least one entire release cycle for one engineer).
Updated•12 years ago
|
Resolution: INVALID → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•