418603 - Boolean logic for filter criteria, operating on a single set of actions (combine/chain filters)

Status: RESOLVED DUPLICATE of bug 297852

(MailNews Core :: Filters, enhancement)

Description

[chrizilla]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: 1.5.0.10

More complex filters are needed: It should be possible to combine filters.

For examle: if (A or B) and (C or D or E) then [action] 

Reproducible: Always

Comment 1

[Magnus Melin [:mkmelin]]

Please refrain from adding keywords that make no sense, and/or means things you aren't able to evaluate.

Confirming RFE.

Comment 2

[Wayne Mery (:wsmwk)]

STM, highly correlates to bug 297852?

Comment 3

[chrizilla]

Dear Magnus Melin,

I added the keywords to *my best knowledge and belief" and I do think they make sense. Given the the bug ID, there are more than 400.000 right? So it's important that they are categorized somehow, no ? IMHO the keyword description perfectly fitted the bug. But I am open to any contrary explanation or feel welcomed to add info to the description. Don't forget: we all share a common goal. Kind regards, chrizoo

Comment 4

[Wayne Mery (:wsmwk)]

Chrizoo, the important part of the UE keyword definition is "The problem describes a confusing or unhelpful aspect of the _user interface_."  This bug does not fit that definition.

Comment 5

[chrizilla]

Thanks Wayne Mery. Ok. In my eyes it was a "specific [...] suggestion for improvement of the user experience" on my part, relating to an "unhelpful aspect of the user interface" - in particular the Filter UI - since in bug 297852 it says "the filter engine is now capable of processing arbitrarily complex Boolean expressions", but "the UIs have not been updated to allow users to take advantage of this feature" and "obviously the Filter UI must get a corresponding update". (Although I had not found bug 297852 prior to my posting this bug here, sorry). And sorry if I got it wrong. I just thought - given the number of bugs reported so far - bugs without any keyword/category disappear easily in the mass, and if someone else more experienced wants to change the keyword, than that's easily done so, I thought. Kind regards.

Comment 6

[Wayne Mery (:wsmwk)]

continuing the education ... take with a grain of salt, because I have never used the keyword myself :)

(In reply to comment #5)
> Thanks Wayne Mery. Ok. In my eyes it was a "specific [...] suggestion for
> improvement of the user experience" on my part, relating to an "unhelpful
> aspect of the user interface" - in particular the Filter UI - since in bug
> 297852 it says "the filter engine is now capable of processing arbitrarily
> complex Boolean expressions", but "the UIs have not been updated to allow users
> to take advantage of this feature" and "obviously the Filter UI must get a
> corresponding update". (Although I had not found bug 297852 prior to my posting
> this bug here, sorry). And sorry if I got it wrong. 

no problem. Think of it this way - using your interpretation/definition of UE keyword would mean that every bug that affects UI can get a UE keyword. Clearly not a workable definition. 

Other ways to think of it, from my perspective:
- UE should (generally) not be applied to sev=enhancement bugs, because ENH implies a feature that does not yet exist in the product
- UE should mean more than the situation is not just defective or less than perfect, or improves the product. It should mean (IMO) that the information or interface is entirely inappropriate or misleading, very confusing, etc

I'm sure there are other, probably better interpretations.  Perhaps the keyword definition should be updated to add greater clarity.


> I just thought - given the
> number of bugs reported so far - bugs without any keyword/category disappear
> easily in the mass, 

Keywords are used to identify a bug with a specific category of bugs, not to prevent "disappearance" of (or lack of attention to) the bug.

Like "polish", I think UE is difficult to apply uniformly. One person's application (and definition of) "polish" to a specific bug may be inappropriate or mean nothing to several other people.

FWIW, query below. Note: Very low usage of UE.  And several bugs probably shouldn't have it.

https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Core&product=Firefox&product=NSPR&product=Thunderbird&product=Toolkit&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=UE&resolution=---&emailreporter1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

Comment 7

[chrizilla]

OK, I attentively read your comments and of course your reasoning makes a lot of sense. If you guys think that no keyword is better than a possible incorrect one, than I won't add keywords any more.

Comment 9

[bm_witness]

I filed bug 456031 - I did search for similar reports but failed to find one...any how...

The original report used the following example:

For example: if (A or B) and (C or D or E) then [action] 

I'm looking for something similar, but different:

For example: if (A) then [action 1] and if (B) then [action 2]

To use a more literal example:  if A the move to folder 'C', and if 'B' then mark as read.

This can currently be done by writing two nearly identical filters in the UI - one checking for conditions (A && B) to perform [action 2] and one checking for (A && !B) to perform [action 1]. I think many would find it better to be able to write a single filter to do both actions with the second action being a conditional additional action when the first rule is invoked.

HTH

Comment 11

[Ludovic Hirlimann [:Usul]]

(In reply to comment #9)

> 
> I'm looking for something similar, but different:
> 
> For example: if (A) then [action 1] and if (B) then [action 2]
> 
> To use a more literal example:  if A the move to folder 'C', and if 'B' then
> mark as read.

bug 323773

Comment 13

[Wayne Mery (:wsmwk)]

ace - duplicate of bug 297852?

Comment 14

[bm_witness]

I think that would certainly be part of it, but I'm not sure it's entirely related. The big issue with this bug is not simply the filtering but also the application of actions. If the backend functionality referenced in bug 297852 also included the capability to apply actions as noted in this bug, then yes, I agree. If not, then I agree the two are related in UI updates, but this bug also requests backend and UI to support applying more actions.

Comment 15

[:aceman]

Wayne, I would think so from comment 0.
However, I am not sure what exactly is this "combining" or "chaining" of filters. That does not look just like allowing arbitrary boolean expressions (with mixed AND/OR operators).

And comment 9 (comment 14) tacked a new functionality on this, that is not covered by bug 297852.
So either close this as dupe and make [e-mail] file his idea as a separate bug, or make it clear that comment 9 is the new description here.

Comment 16

[bm_witness]

Please reopen bug 456031 that I originally filed instead of opening yet another new one if you close this one as duplicate of 297852.

Comment 17

[Wayne Mery (:wsmwk)]

(In reply to bm_witness from comment #16)
> Please reopen bug 456031 that I originally filed instead of opening yet
> another new one if you close this one as duplicate of 297852.

456031 is properly a duplicate of bug 323773. 323773 just needs a better title.

FPOHTMEH's bug 655452 is perhaps a duplicate of 323773, or stands on its own?

Comment 18

[:aceman]

Ok, so when bm_witness is bug 323773, which he confirmed in bug 456031, then we are set here. Dupe this against 297852.

Comment 19

[:aceman]

... bm_witness's idea ...