Closed Bug 577819 Opened 14 years ago Closed 14 years ago

Messages with multiple tags don't show up in tag-based virtual folders

Categories

(Thunderbird :: Search, defect)

x86
Windows Vista
defect
Not set
major

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: peter-panino, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: ux-error-prevention, Whiteboard: needs followup bugs along bug 379465)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; de-DE; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 GTB7.1 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; de-DE; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Mnenhy/0.8.3 SubSwitch/0.9.16 Thunderbird/3.1

Example: A message is located in the Sent folder. The message has the tags "Answer expected" and "Finance". I have two virtual tag-based folders "Answer expected" (condition: TAG IS "Answer expected") and "Finance" (condition: TAG IS "Finance") (of course without quotes). If the message has only one tag (i.e. "Answer expected" OR "Finance") then it shows up in the respective virtual folder. If the message has both tags then it doesn't show up in any of the both virtual folders!

Also when making a global tag-based search (Ctrl-Shift-F) based on both tags (conditions: TAG IS "Answer expected" AND TAG IS "Finance") then the message which has both tags is not found!

Reproducible: Always

Steps to Reproduce:
1. Apply the tags "Answer expected" and "Finance" to a message.
2. Create two tag-based virtual folders as explained above.
3. Look in the two tag-based virtual folders and verify that the message is not found there.
Actual Results:  
The message with two tags is not found in the respective tag-based virtual folder.

Expected Results:  
The message with two tags should be found in the respective tag-based virtual folder.
Component: General → Search
QA Contact: general → search
Version: unspecified → 3.1
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1

Peter, you're using the wrong search operator. Instead of TAGS IS (note that the field is TAGS, not TAG), for what you want you have to use TAGS CONTAINS which works like a charm on my POP3 folder (if correct folder is set in saved search).
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
(In reply to comment #1)
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.7) Gecko/20100713
> Lightning/1.0b2 Thunderbird/3.1.1
> 
> Peter, you're using the wrong search operator. Instead of TAGS IS (note that
> the field is TAGS, not TAG), for what you want you have to use TAGS CONTAINS
> which works like a charm on my POP3 folder (if correct folder is set in saved
> search).

Thomas, thank you for the hint - it now works with CONTAINS!

However, the alternative of having TAG (singular) as "from" field IMO would offer an advantage over TAGS (plural), as the case of "TAGS IS" selector makes sense only if one tag is used per message, where TAG would allow also multiple tags (if implemented in this manner). If the "from" field was TAG then the user could combine several conditions with OR to achieve what "TAGS CONTAINS" does now. In addition TAG could combine conditions with AND to achieve what TAGS would not exactly get when combining tags with AND!
Along the lines of comment 2, I think there is several usability problems here (first thoughts, needs more tests and deeper understanding):

1) People don't realize that "Tags" is the field name for searching the string/array(?) of ALL tags that are attached to a message

2) it would be much more intuitive to define such tag searches with a single-tag field and IS-operator:

Proposed new single-tag field:

Match any of the following:
Any_Tag IS tagfoo (OR)
Any_Tag IS tagbar
-> this would return messages with tagfoo, tagbar, or both of these tags.

3) the bigger problem is that we are currently forcing the user to use "CONTAINS" operator, pretending to do a substring search (which is the meaning of CONTAINS in any other field), but we don't:

STR

Have msgs with these tags:

msg1: tagfoo (e.g. "Win")
msg2: tagfoobaz (e.g. "WinXP")

Search:
Any/All of the following:
Tags CONTAINS tagfoo

-> This will return msg1, but not msg2 (Bug; expected: contains -> substring search -> must return both!)
-> wrong UI element: for contains/doesn't contain operators, we must show text input box for user to enter partial string, not dropdown of existing tags
-> a related problem here is that it's impossible to search for substrings of a given tag, like search for substring "tagfoo" to find tag "tagfoobaz", even if "tagfoo" is NOT a tag.

We need to clarify these problems and the required/desired UI and behaviour and file bugs to correct/improve the UI and behaviour.
Whiteboard: needs followup bugs along bug 379465
Blocks: 379465
No longer blocks: 379465
Depends on: 379465
See Also: → 395985
You need to log in before you can comment on or make changes to this bug.