238631 - [RFE] "sort by flag" should sort in a different order

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[Lisa]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

The current sort order when sorting by flag is as follows:
1. flagged: oldest to newest
2. not flagged: oldest to newest
Or the reverse when sorted the opposite way.

This places flagged messages near the oldest of the unflagged messages, making
"sort by flag" completely useless as a permanent sort order (for people who
always want to have their flagged messages as reminders but also want their
newest messages in view so they can see their new messages new messages).

I propose that the sort order for "sort by flag" be changed to:
1. flagged: newest to oldest
2. not flagged: newest to oldest
Or the reverse, either way placing flagged messages next to the newest unflagged
messages.

Reproducible: Always
Steps to Reproduce:

Comment 1

[R.K.Aa.]

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

Comment 2

[Lisa]

I don't think those two bugs are the same. 196696 is asking for the ability to
use multiple sort criteria, which is a dup of 57898. What I'm saying is that
sorting by flag all by itself should behave differently than it does right now.
I don't think the current "sort by flag" is logical, since it appears to be
trying to also take date into account but is doing so in a counterintuitive way.

Comment 3

[Mike Cowperthwaite]

It's not actually date, but order received, that is the secondary sort 
criterion.  You can see the difference by creating a folder and copying messages 
into it in some ad hoc fashion: order received is the order they were placed 
into the folder.  Typically, especially for an Inbox, that *is* the date order, 
or close to it.

It sounds like you would like to see the Ascending/Descending ordering of Flag 
the reverse of what it is -- but only because your particular desired use for 
flags would work out just right when you sorted by "Flags, Ascending" with its 
implied secondary criterion of "Order Received, Ascending."  But that might 
break someone else's current use of sort-by-Flag.  Making that order specifiable 
seems a fair amount of work for little gain.

Having multiple sort criteria would allow you to specify "First sort by Flags, 
Ascending; then by Date, Descending."  Or, perhaps even nicer, "first sort by 
Label, Ascending; then by Date, Descending."

Comment 4

[Lisa]

I'm not against multiple sort criteria. I'm actually for it. I just think that
my request is different and as such should get separate consideration.

If I could think of a good reason for having sort by flag the way it is now, I
wouldn't have bothered with this bug. I can't think of any. To me, my proposed
method seems more logical, not simply "good for me."

I'm also not the only one who finds this sort method illogical. It could be that
more people aren't speaking up for this change simply because "sort by flag" is
not commonly used. However, I haven't heard anyone say they like the current
method. If those people who do want to use "sort by flag" are all unhappy with
the method, what's the harm in changing? So far all I've heard is that "it is
what it is, so why should we change it?" I don't think that's a good enough
reason not to at least consider the change.

Comment 5

[Grey Hodge (jX)]

This bug can be fixed by multiple sort criteria, which would resolve a bunch of
thse types of bugs. <suckup> It's an excellent suggestion though. </suckup>

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

Comment 6

[Mike Cowperthwaite]

Reopening; I agree that this is not the same as multi-criterion sort.

I also agree, after looking at this some more, that an Ascending sort of Flags 
should put Flagged messages at the bottom, just as an Ascending sort by Unread 
puts the Unread messages at the bottom, and an Ascending sort by Date puts the 
newest (most important) messages at the bottom.

See also bug 121588.

Comment 7

[Mike Cowperthwaite]

Confirming.
See also bug 181143.

Comment 8

[Charles Oliver Nutter]

I've added a vote for this bug, because I agree that the current sort order when
sorting by flags is totally worthless. I don't think anyone would choose to sort
by flags intending that flagged messages go to the least significant end of the
list, next to the oldest messages. Lisa has it right.

I think it also qualifies as a bug rather than an RFE because no other mail
client I've used sorts flags this way, and it's totally counter-intuitive (or at
least none of the Outlook series or Novell's Groupwise series work this way.)

Comment 9

[Marat Khalili]

I also voted for this bug, however I think it should be Flag -> Read -> Date,
while Read should be Read -> Flag -> Date, only this way these modes are
sensible. Before telling me that my request is duplicate for multiple sort
please apply all arguments that saved Flag -> Date in this thread. Obviously
neither unread nor flagged messages should ever be buried. Please tell me if you
think it's not always true.

Comment 10

[Charles Oliver Nutter]

I disagree with comment #9...no other sorts also take "Read" into 
consideration (unless sorting by "Read"), and sorting by "Flag" should be no 
different. Other sorts do consider "Date" automatically though, so 
having "Flag" sorts consider both "Flag" and "Date" (and do it correctly) is 
appropriate. Once multiple sort criteria is supported, however, I think 
automatically sorting by date should be explicitly stated, i.e. instead of 
saying "sort by Subject", say "sort by Subject, Date"

Comment 11

[Mike Cowperthwaite]

*** Bug 247341 has been marked as a duplicate of this bug. ***

Comment 12

[Mike Cowperthwaite]

Duplicate points out that in addition to Flag and Label(bug 121588), Status and 
Priority are also sorted 'incorrectly' in that the presumably important items 
are left at the bottom of the heap -- and that the 'important' part of the sort 
is usually the 'empty' string.

Comment 13

[David :Bienvenu]

this would be easy to do, I think.

Comment 14

[Marshall Levin]

*PLEASE* make it possible to view my flagged messages in reverse chronological order!

Comment 15

[Troy W.]

This feature is absolutely essential to me, and is the only thing preventing me from migrating from Outlook. I deal with hundreds of emails a day and I need the ability to flag certain messages so that they stay at the top of the pack and don't get buried.

If this feature is easy to implement, then I beg you to please implement it in the  next version. :)

Comment 16

[David :Bienvenu]

Attachment: add group by flagged status, which should satisfy this request

If we enable grouping by flagged state, you can see your new messages together. Also finishes enabling group by attachment status.

Comment 17

[Mike Cowperthwaite]

To niggle: the patch actually fixes bug 278263, while providing a workaround 
for this bug.

Comment 18

[Troy W.]

On somewhat the same note, what might also be even more handy would be the ability to sort by Label. There's only one flag, but 5 labels. 

Comment 19

[(not reading, please use [e-mail] instead)]

Comment on attachment 224076 [details] [diff] [review]
add group by flagged status, which should satisfy this request

sr=sspitzer, acting as sr for mscott when he is away.

Comment 20

[David :Bienvenu]

this patch was checked in on trunk and 1.8.1 branch

Comment 21

[Marek Stępień [:marcoos, inactive]]

Comment on attachment 224076 [details] [diff] [review]
add group by flagged status, which should satisfy this request

After this patch there are two entities called "flagged" in messenger.properties - in lines 197 and 230.

This also breaks l10n builds (compare-locales goes nuts).

Comment 22

[David :Bienvenu]

ok, thx, I've fixed all the dups...sorry about that; it didn't cause my builds any problems.

Comment 23

[David :Bienvenu]

Attachment: use groupFlagged property instead of flagged

use a different property to avoid conflict with existing property

Comment 24

[Marek Stępień [:marcoos, inactive]]

It didn't cause your builds any problems, because doubled property does not break anything and compare-locales is - due to obvious reasons - not run for en-US. ;-)

After checking in attachment 224326 [details] [diff] [review] the tinderboxen of properly updated l10ns are now green. Thanks. :)

Comment 25

[[e-mail]]

Interestingly nsMsgDBView.cpp contains this line of code:
*result = !(bits & MSG_FLAG_MARKED)  //make flagged come out on top.