759999 - Custom searching doesn't work as expected

Status: RESOLVED DUPLICATE of bug 677757

(Bugzilla :: Query/Bug List, defect)

Description

[Simon Green]

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 [e-mail] to [e-mail] 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 [e-mail] at any time (for example bug 1)

Comment 1

[:glob ✱]

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 = '[e-mail]'
       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

[Max Kanat-Alexander]

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 ] [ [e-mail] ]
           [ 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.

Comment 3

[Max Kanat-Alexander]

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).