Open Bug 218853 Opened 21 years ago Updated 2 years ago

Status=(blank) option (a.k.a. "Unread"), or include as part of Status=New criterion

Categories

(MailNews Core :: Search, defect)

defect

Tracking

(Not tracked)

People

(Reporter: fmoraes, Assigned: aceman)

References

Details

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

A view created with a status of either Read or New does not produce the expected
results. It seems like the view is being based on the read/unread status and not
on the status column itself.

Reproducible: Always

Steps to Reproduce:
1. Create new message view from View->Messages->Customize... menu
2. Hit new, give it a name and select Match any of the following
3. Make the first criteria Status is Read
4. Click on More, and make the second criteria Status is New

Click ok and ok again. Select the new view. 

Actual Results:  
Replied emails will still show in the view.

Expected Results:  
New/replied emails shoud not show in the view.



This is snippet from mailViews.dat (not sure why enabled="no")

name="Not replied"
enabled="no"
type="1"
condition="OR (status,is,read) OR (status,is,new)"
dupe of bug 78418?  status=read seemed to work fine for me, but status=new fails
as described.
correction: status=new works when the status column actually says "New," like
when a message just comes in.  If a message has been left or re-marked as
unread, a view on status=new doesn't pick it up (note in such cases the status
column is empty).

This makes it cumbersome and unintuitive to recreate the default view "Unread"
as part of a customized view, but it seems like the functionality is correct,
perhaps *too correct.*
Since the status field can be EMPTY at some points, it seems the filter editor 
should provide (empty) as an option for the value.  I guess that would be an 
enhancement request, which I don't see another bug about.  We could change this 
bug to be about that.

In the meantime: the filter desired in the report is called "not replied" -- why 
not use    Status, Is Not, Replied    for the criterion?
Old summary: View with status of either read or new does not work
Reporter hasn't replied since the original report, so I'm morphing the bug as
described in comment 3.  Considering the status=read part as wfm.

To recap, the issue is that messages manually marked as unread don't carry
Status=New like new unread messages do.  It would be useful to filter on a
Status=(blank) criterion.  I'm not sure how much value there is in
distinguishing that from Status=New, though, so the two could also be treated as
the same thing.

This is either minor or enhancement, going with minor because of the possibility
of confounding "unread" and "new" states.
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: View with status of either read or new does not work → Status=(blank) option, or include as part of Status=New criterion
Whiteboard: [good first bug]
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Assignee: mail → nobody
Component: MailNews: Main Mail Window → MailNews: Search
OS: Windows XP → All
Product: Mozilla Application Suite → Core
QA Contact: esther → search
Hardware: PC → All
Summary: Status=(blank) option, or include as part of Status=New criterion → Status=(blank) option (a.k.a. "Unread"), or include as part of Status=New criterion
Product: Core → MailNews Core
Unread messages (either marked Read/Unread manually) or after TB restart, loose the New flag and that is by design.

Can somebody restate what is actually wanted here?
Why (Status, isn't, Read) criteria is not sufficient? That is also returns e.g. Replied messages, that if they are also marked Unread?

Nevertheless, adding (Status,is,<blank>) as a shortcut for AND(Status,isn't,Read) AND(Status,isn't,Replied)AND(Status,isn't,New) AND(Status,isn't,Starred) AND(Status,isn't,Forwarded) may be worthwhile.
Flags: needinfo?(mail124)
Whiteboard: [good first bug]
I think you can take this bug as an enhancement request to allow searching on (Status,is,<blank>), as you suggested.

The existing behavior of distinguishing between "new" and <blank> statuses by dropping the "new" status after switching folders is probably unintuitive for some, especially for users who do not have the status column visible. Such users might try making a saved search and expect that the list of possible statuses to filter on is exhaustive, i.e. that "New" refers to any item whose status is not one of the other listed statuses. Adding <blank> into the list at least helps clue people in to the difference.
Flags: needinfo?(mail124)
This can be done after bug 870236 lands as the patches would collide.
Depends on: 870236
Attached patch PatchSplinter Review
"Status" is "Blank" shows the messages with blank status fields.
Attachment #814435 - Flags: feedback?(acelists)
Comment on attachment 814435 [details] [diff] [review]
Patch

Review of attachment 814435 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry, but this does not work for me. When I try "status isn't blank" it returns SOME messages that have status=blank and some that have status=Read.

::: mail/base/content/mailWidgets.xml
@@ +1735,5 @@
>          </xul:menupopup>
>        </xul:menulist>
>        <xul:menulist flex="1" class="search-value-menulist" xbl:inherits="disabled">
>          <xul:menupopup class="search-value-popup">
> +          <xul:menuitem value="0" stringTag="blank" class="search-value-menuitem"/> 

Is there a trailing space here?

::: mailnews/base/search/src/nsMsgSearchTerm.cpp
@@ +276,5 @@
>  
>    return (found) ? NS_OK : NS_ERROR_INVALID_ARG;
>  }
>  
> +const uint32_t Blank =0;

Space after =.
Attachment #814435 - Flags: feedback?(acelists) → feedback-
I'll assign this to me to not loose track of the bug. But if you Suyash want to finish it, you can take it any time;)
Assignee: nobody → acelists
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: