40966 - Implement negation of all boolean chart operators OR expressions

Status: RESOLVED DUPLICATE of bug 245272

(Bugzilla :: Query/Bug List, enhancement, P3)

Description

[Sean Richardson]

Currently Bugzilla has no general way to invert any search term.

In most cases it is possible to "reword" a query to do a desired search
in another way, but not always. 

For example, 
   not( [assigned_to] [equal to] [[e-mail]] )
could be rewritten as 
   [assigned_to] [not equal to] [[e-mail]] 

However, since there are not operators for all variants of [changed],
it is possible to rework 
   not( [assigned_to] [changed after] [1999-12-31] )
to 
   [assigned_to] [changed before] [2000-01-01]
but it is not possible to rework
   not( [assigned_to] [changed to] [[e-mail]] )
to a simple expression.

The problem is that three of the operators do not have a symmetrical 
corresponding operator. 

Three ways to proceed:

1. Add in the missing operators. That is, pair up
      notcasesubstring with casesubstring,
      notchangedto with changedto,
      notchangedby with changedby,
   and, for completeness, add in 
      unchanged 
   as a unary operator to provide a way to express the currently inexpressible
      not( [assigned_to] [changed after] [1980-01-01] )
   without the extraneous date comparison. That would become the simpler
      [assigned_to] [unchanged] [""]
   See "Option 1" in the attachment. (Pull down the second <SELECT>).

2. Add a selectable negation operator for each boolean chart expression.
   That is, for each expression, allow its result to be negated or not.
   See "Option 2" in the attachment. (Pull down the first <SELECT>).

3. Generalize the boolean chart to allow any of "and", "and not", "or", or
   "or not" to apply to any expression. ("Or not" expression) would mean
   (Or(not(expression))).
   See "Option 2" in the attachment. (Pull down the first <SELECT>).

Depending on implementation details, options 2 and 3, while providing
(excuse the pun) freedom of expression, might be too computationally
expensive.

Comment 1

[Sean Richardson]

Attachment: Example boolean charts for the three options

Comment 2

[Andreas Franke (gone)]

In Option 3 it is not obvious to me how _And_ and _Or_ rows are bracketed.

Comment 3

[Sean Richardson]

Good point. Actually, parentheses would work exactly the same, but if that
wasn't obvious, option 3 is probably more complicated than it is worth.

Normal boolean charts for a query, like Bugzilla's current implementation, 
only allow expressions like 
      (term1 OR term2) 
  AND (term3 OR term4)
... with implicit parentheses around each line.
Option 3 would both provide more freedom and require more care: there would
still be implicit parentheses around each line, but *within* a line you could
get into trouble. For instance, writing:
          (term1 OR term2 AND term3)
  AND NOT (term4)
when you mean
          (term1 OR term2)
      AND (term3)
  AND NOT (term4)

With a little care, there would be no problem, so long as you treat each
row as having parentheses and group terms accordingly, but the potential
*does* exist for additional boneheaded goofs.

That said, option 1 would be the simplest to implement, the simplest to  
understand, and render the compexities of options 2 or 3 unnecessary.
If the negation of all binary operators were available, the current boolean 
chart format would suffice.

Comment 4

[Andreas Franke (gone)]

-> Bugzilla product, Query component, reassigning.

Comment 5

[Dave Miller [:justdave]]

We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.

Comment 6

[Dave Miller [:justdave]]

Enhancements which don't currently have patches on them which are targetted at
2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. 
Consideration will be taken for moving items back to 2.18 on a case-by-case
basis (but is unlikely for enhancements)

Comment 7

[Joel Peshkin]

*** This bug has been marked as a duplicate of 245272 ***