Closed
Bug 238631
Opened 21 years ago
Closed 18 years ago
[RFE] "sort by flag" should sort in a different order
Categories
(SeaMonkey :: MailNews: Message Display, enhancement)
SeaMonkey
MailNews: Message Display
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: lady.of.dreams, Assigned: Bienvenu)
References
Details
Attachments
(2 files)
(deleted),
patch
|
moco
:
superreview+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Details | Diff | Splinter Review |
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:
*** This bug has been marked as a duplicate of 196696 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Comment 3•21 years ago
|
||
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."
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•21 years ago
|
||
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 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → DUPLICATE
Comment 6•21 years ago
|
||
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.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Comment 7•21 years ago
|
||
Confirming.
See also bug 181143.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•21 years ago
|
OS: Windows XP → All
Hardware: PC → All
Comment 8•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
*** Bug 247341 has been marked as a duplicate of this bug. ***
Comment 12•20 years ago
|
||
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.
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 14•19 years ago
|
||
*PLEASE* make it possible to view my flagged messages in reverse chronological order!
Comment 15•18 years ago
|
||
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. :)
Assignee | ||
Comment 16•18 years ago
|
||
If we enable grouping by flagged state, you can see your new messages together. Also finishes enabling group by attachment status.
Attachment #224076 -
Flags: superreview?(sspitzer)
Comment 17•18 years ago
|
||
To niggle: the patch actually fixes bug 278263, while providing a workaround
for this bug.
Comment 18•18 years ago
|
||
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•18 years ago
|
||
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.
Attachment #224076 -
Flags: superreview?(sspitzer) → superreview+
Assignee | ||
Comment 20•18 years ago
|
||
this patch was checked in on trunk and 1.8.1 branch
Comment 21•18 years ago
|
||
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).
Assignee | ||
Comment 22•18 years ago
|
||
ok, thx, I've fixed all the dups...sorry about that; it didn't cause my builds any problems.
Status: NEW → RESOLVED
Closed: 21 years ago → 18 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 23•18 years ago
|
||
use a different property to avoid conflict with existing property
Comment 24•18 years ago
|
||
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•18 years ago
|
||
Interestingly nsMsgDBView.cpp contains this line of code:
*result = !(bits & MSG_FLAG_MARKED) //make flagged come out on top.
You need to log in
before you can comment on or make changes to this bug.
Description
•