6.39 KB, patch
|Details | Diff | Splinter Review|
3.63 KB, patch
|Details | Diff | Splinter Review|
39.01 KB, image/png
Sort order for e-mail folders and newsgroups not configurable by default.
do you mean the default is not configurable? Because the sort order for each individually IS configurable. (sie sind einzeln einstellbar, ABER der standard für ALLE ist nicht setzbar)
The default settings for ALL newsgroups (sort order) are not configurable.
There is little reason to have a configurable default, because once you make your sort-order selection, it remembers it. If there were a default, it would only really apply to the very first time you use the program, and the FEW times you would add a new folder. Still would be nice to have though, i guess.
I agree with the previous poster. Nice to have (especially if you're adding a lot of folders or subscribing to a lot of newsgroups at once) but severity major???
yes, major. The first LOOK at the application is very important and if you have to do such 'trips' I have done to get the same as I had before on an old NEWS reader you won't use the product at all. May be I have used the wrong flag but IMHO it is important to get new users away from their old readers and to Mozilla.
The fist thing a new user does is try out some of the "basic" features (browse, send an email, add an address). They for sure will not mess with a relatively obscure preference. I have all my folders sorted by date *descending* (NOT the default) and had to do it all by hand. It's not a big deal to click on a title heading - for me, it's become somthing like a "habbit" to reverse the default sort order. I too would like this feature, but the severity is really "Enhancement", sorry. I suggest you add some keywords to get this thing going (e.g. mozilla0.9.3, ui).
> I have all my folders sorted by date *descending* (NOT the default) > and had to do it all by hand. It's not a big deal to click on a > title heading - for me, it's become somthing like a "habbit" > to reverse the default sort order. We are living in the year 2001 and manual settings for each group/folder is IMHO not good enough for a modern mail client like Mozilla want to be.
Marking as a NEW enhancement request.
Severity: major → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
It doesn't have to be as a configurable pref. Why not just let Moz remember the sort order between sessions (it still doesn't do so)
Would be interesting to know how many users want a order by date desc. Nominating for 1.1
Dup of bug 32246, "[FEATURE] Default sort order pref"?
*** Bug 32246 has been marked as a duplicate of this bug. ***
Who implemented Sort per folder? (Bug 17074) That's an awful feature. Given all my newsgroups and mailboxes, I have hundreds of folders. To have to set the sorting each time I open another folder is a real pain in the neck. I'd like to be able to set an option to sort *every* folder by date, descending. Mozilla needs a configuration option for sorting. What would be nice for example is; config option 1 is to thread all messages. Option 2 is to sort by date/time. Option 3 is to sort alphabetically. Option 4 is to sort by priority. So, if two messages were to have the exact same send date/time, they would then proceed to being sorted alphabetically (by the author's name - another option - sort alphabetically by subject, author's name, etc..) If two messages were sent at the same time by the same author, they'd then be sorted by priority. etc... Of course, this would be more useful if your second sort option wasn't date/time (since date/time is fairly unique.)
I agree with Duke. I searched for an RFE to make per-folder sorting optional but couldn't find one, so I filed bug 175502. Wouldn't that do what you want, reporter?
*** Bug 172427 has been marked as a duplicate of this bug. ***
This bug is related to Bug #180604 - Sort order gets lost and summary file needs to be rebuilt, which, if the default were set to what the user wants, would either not happen or proceed more rapidly. It is also related to Bug #190337 - Need for a timestamp header line for date and time message is received, and search and sort on that value. Needed to make functions based on date work when sender's system clock unrelated to real world time.
I also agree with Duke in Comment 13. Any kind of situation that causes the settings to be lost means each newsgroup needs to have its settings reset individually; if there were a global default, this wouldn't be necessary, or not *as* necessary. And this shouldn't just be the Sort setting, either; I want all the newsgroups to default to View | Messages | by Thread with Unread. I haven't played around much with the MailViews feature (that dropdown at the top of the list of messages), but that setting also should have a default.
*** Bug 225367 has been marked as a duplicate of this bug. ***
Any further action on this? It is still a priority for me, as it is a constant chore.
related: bug 123786
*** Bug 274214 has been marked as a duplicate of this bug. ***
Since my bug report https://bugzilla.mozilla.org/show_bug.cgi?id=274214 has been marked as duplicate... Not having configurable sort orders (I like to use descending/threaded, date received for most of my mail and all of my news-groups) can get a pain in the ass, together with Mozilla loosing all metainformation for mail, if the IMAP server disconnents after a period of inactivity. Every time this happens, you'll have to go thru all your mail folders again, setting sort order to what you like again. This isn't really what I want. I'd like to have it automaticaly inherit a default for all new folders --- since all folder information is lost too, Mozilla does a complete download of the IMAP mailbox. Everything is "new" then. The defaults would apply. It is not only something "Nice to have". It is a neccessity to have a way setting defaults for sorting!
> It is not only something "Nice to have". It is a neccessity to have a way > setting defaults for sorting! Totally agree!
I totally agree to Thomas Schweikle's comment #22. I have a lot of mailinglists subscribed and filtered to different IMAP-folders. I have to select every single folder, wait for it to download all headers, click twice on the threaded view, collapse all, and scroll up to the top. I would be totally happy with a user.js option to set the default sorting. Hmm, this bug was opened almost 4 years ago. I wonder if anyone still cares...
i also desperately want this. for me the use it: set default to NEWEST first instead of now. i'm sad to see that after almost 4 years this still isn't implemented :(
someone wondered how many people would like to have their emails in descending order (newest on top). well for example me. i definitely want to have my emails in descending/threaded order. which means descending and also threaded. this behavior is not configurable and is imho a disadvantage in thunderbird. also thunderbird remembers the default sort order but sometimes for apparently no reason the connection to an imap-server gets lost or something happens and you have to subscribe all your folders new and have to set the sort order for all these folders new. and when you add, like me, every month like 30-40 new subscribed folders, you have to repeat the same procedure which really is a pain in the ass. but after i saw, that this bug has been filed over 4 years ago it apparently doesn't matter and it will not be implemented. well we'll see. regards ianus
I also want to see a configurable default sort order. Like others who have replied, I frequently need to rebuild by .msf files, and each time that happens, I need to manually go into each folder to change the sort order. Quite annoying really .. How hard would it be to add this feature anyways? It really shouldn't be too difficult, even though I can't figure it out myself :) Is it something that could be configured by hacking any of the .js or .properties inside the jars?
I'd also agree with most of the posters in here as it's a real pain going through and changing the sort order for every folder. I personally don't think that it needs to be remembered on a per folder basis - I'd be happy with a single global setting or perhaps a per account setting so that you could have one setting for emails, one for RSS feeds, one for news groups etc.
Maybe the bug should be moved to Thunderbird, as it also applies and chances are higher that it gets fixed in there!?
(In reply to comment #29) > Maybe the bug should be moved to Thunderbird, as it also applies and chances > are > higher that it gets fixed in there!? File new bug for TB and reference this bug#
Component: MailNews: Main Mail Window → MailNews: Backend
Product: Mozilla Application Suite → Core
*** Bug 314599 has been marked as a duplicate of this bug. ***
Moved to core to reflect both the application suite and thunderbird.
Here's a proposed patch which adds a (hidden) "mailnews.default_sort_direction_descending" setting... if set to true, newly opened Mail folders or News groups will be sorted in descending order by default. Build successfully tested with the Thunderbird 1.5RC2 source tree. Any chances we'll see this feature getting added for Thunderbird 2.0...? (I'll leave it to others to decide on the proper place for this preference in the Options UI, either edit prefs.js or use the Config Editor for now.)
*** Bug 324989 has been marked as a duplicate of this bug. ***
> We are living in the year 2001 and manual settings for each group/folder is IMHO > not good enough for a modern mail client like Mozilla want to be. And five years later this wish has not changed!!
Comment on attachment 207328 [details] [diff] [review] Patch to add a "default_sort_direction_descending" setting you need to request review of a particular person in order to get a review. I'll look at this.
Attachment #207328 - Flags: review? → review?(bienvenu)
Comment on attachment 207328 [details] [diff] [review] Patch to add a "default_sort_direction_descending" setting I'm thinking it would be better to have a pref that specifies the default sort order (ascending/descending) and default it to ascending. We could also have a pref for the default sort column. It would be easiest if we used the int values for these settings as prefs, but that's not very user friendly, even if it is a hidden pref.
Thanks for looking into this, David. > I'm thinking it would be better to have a pref that specifies the default > sort order (ascending/descending) and default it to ascending. I agree, my first patch was primarily an attempt to get the ball rolling, again (not very successfully, apparently). > It would be easiest if we used the int values for these settings as prefs, > but that's not very user friendly, even if it is a hidden pref. Yes, but actually, I would prefer them to be visible instead - please find attached a second attempt at dealing with the issue in a more systematic way. I believe the right place for adding the default sort order is actually nsMsgDatabase, not nsDBFolderInfo... there's already nsMsgDatabase::GetDefaultSortType, so I've added GetDefaultSortOrder and modified these two methods to read their default from the prefs, if available ("mailnews.default_sort_type" and "mailnews.default_sort_order", respectively). Second, I'm including a proposal for adding these settings to the Advanced -> General preferences tab (see screenshot in separate attachment). I tried to reuse existing l10n strings where available, but if you think it's messy to include two additional DTDs, I could also add all of them to advanced.dtd. Looking forward to your comments! - Feel free to adapt this patch as needed (it's against THUNDERBIRD_1_5_0_5_RELEASE, but seems to apply fine to MOZILLA_1_8_BRANCH as well).
(The order in the drop down list is modeled after the View -> Sort by menu.)
The best way to present it to the user would be to allow setting the sort order as usual, then offer the option: "Set this as the default sort order for all folders in the account?" Then also have an additional choice in the Account Settings | Copies and Folders page to set the default sort order.
exactly comment #37. and there also should be a (global) pref for sort order and sort column within threads, to also be remembered on a per folder basis ideally. the current problem is that for news feeds, threaded discussions cannot be followed as neither az nor za date sorting is supported (much less any other column). order received is not related to date or order posted..
Comment on attachment 231237 [details] [diff] [review] Patch to add user-configurable default sort settings David, I'm not sure if you were notified when I attached my second version of the patch (since you're neither the assignee nor on the Cc list). I'm now adding the review flag again... and as far as the latest comments are concerned, I think it doesn't make sense to (try to) address all sort-related feature requests with a patch for this particular bug. Making it an account-specific setting doesn't really seem feasible to me, but I see that there are reasons why people would like to have different defaults for mail messages on the one hand and for news messages on the other - so, maybe it makes sense to add separate prefs for nsNewsDatabase, too (i.e. "mailnews.default_news_sort_order" and "mailnews.default_news_sort_type", which would override the generic ones from nsMsgDatabase)?
Attachment #231237 - Flags: review?(bienvenu)
Comment on attachment 231237 [details] [diff] [review] Patch to add user-configurable default sort settings thx for the patch! - a few comments: in mailnews.js, can you add comments about what those two default values mean and which source file the values are defined in? in nsIMsgDatabase.idl, you need a new uuid for nsIMsgDatabase because you've changed the interface (run uuidgen) If we decide to take this for 2.0, we'd probably want to put defaultSortOrder at the end of the interface to have some hope of keeping binary compatibility. But for the trunk, we'd put it where you have it, so I guess you should just leave it there and I'll deal with the 2.0 branch at checkin time... why can't this: + GetIntPref("mailnews.default_sort_order", &defaultSortOrder); + + if ((nsMsgViewSortOrderValue) defaultSortOrder == nsMsgViewSortOrder::descending) + *aDefaultSortOrder = nsMsgViewSortOrder::descending; + else + *aDefaultSortOrder = nsMsgViewSortOrder::ascending; just be GetIntPref("mailnews.default_sort_order, aDefaultSortOrder); ? The pref has a default value so we should be able to just pass that on... I'm not sure if Scott's going to want a UI for setting these values. We'll have to check with him for that.
Attachment #231237 - Flags: review?(bienvenu) → review-
Thanks for your review, David. Here is v2 of the patch, which also includes my earlier suggestion: > maybe it makes sense to add separate prefs for nsNewsDatabase, too > (i.e. "mailnews.default_news_sort_order" and > "mailnews.default_news_sort_type", which would override the generic > ones from nsMsgDatabase)? On the other hand, I have omitted the UI related changes for the time being. > in mailnews.js, can you add comments about what those two default values > mean and which source file the values are defined in? Done. > in nsIMsgDatabase.idl, you need a new uuid for nsIMsgDatabase because > you've changed the interface (run uuidgen) Done. > But for the trunk, we'd put it where you have it, so I guess you should > just leave it there and I'll deal with the 2.0 branch at checkin time... Ok, left as is. > why can't this: > > + GetIntPref("mailnews.default_sort_order", &defaultSortOrder); > + > + if ((nsMsgViewSortOrderValue) defaultSortOrder == nsMsgViewSortOrder::descending) > + *aDefaultSortOrder = nsMsgViewSortOrder::descending; > + else > + *aDefaultSortOrder = nsMsgViewSortOrder::ascending; > > > just be > > GetIntPref("mailnews.default_sort_order, aDefaultSortOrder); > > ? > > The pref has a default value so we should be able to just pass that on... Well, I was thinking of the case where a user would set it to some bogus int value by editing prefs.js (let's say "10", either inadvertently or intentionally), especially if it is a hidden pref. Not sure how the rest of TB's code would deal with this, then... - or maybe it's just my "never trust user supplied input" paranoia? ;) We can leave it out if you think it's overkill. > I'm not sure if Scott's going to want a UI for setting these values. > We'll have to check with him for that. How do we proceed? Should I attach a separate patch containing the UI related changes only and ask him for a review? (Or would it be ok to use the screenshot attachment for requesting a "review"?)
Comment on attachment 232571 [details] [diff] [review] Patch v2, backend changes only (no UI modifications) thx for the patch - I think the handling of the invalid values could be a little tighter - something like: GetIntPref("mailnews.default_news_sort_order", aDefaultSortOrder); + + if (*aDefaultSortOrder != nsMsgViewSortOrder::descending) *aDefaultSortOrder = nsMsgViewSortOrder::ascending; with that change, we'd be good to go.
> I think the handling of the invalid values could be a little tighter Indeed, thanks for pointing this out. Hopefully I got it right this time... attached is v3.
Comment on attachment 233353 [details] [diff] [review] [checked in on trunk branch] Patch v3 (backend changes only) looks good - thx! I'll try to check this in this weekend...
Attachment #233353 - Flags: review?(bienvenu) → review+
I've checked the backend fix into the trunk, thx, Kaspar!
Great work guys. Though I don't know what the backend change does, I have a question about the 'proposed extension for the preferences UI': threaded sort being enabled/disabled by default. Cheers, Mark
setting the default sort type to 0x16, decimal 22, byThread, *should* make the default be threaded, though I'm not 100% sure, because now we use the viewFlags to control thread/non-threadedness, and allow the sort type to specify how the top level threads should be sorted.
'Sort by Thread' was always a proxy value which translated to 'Threaded'+'Sort By Order Received'. It's not a value that should be relied on, and if I'd looked at this patch earlier, I would have said not to use '22' as the default value for news. If '22' behaves as the old Sort By | Thread menu used to behave (xref bug 219620) then it's impossible to have a default view of Threaded+By Date, which I prefer to Threaded+By Order Received. In fact, I'd go so far as to say there should be a third pref for both the mail and news items explicitly controlling whether the default is Threaded, Unthreaded or Grouped -- just as there are three group in the Sort By menu.
yes, you'd need to add a pref for default view flags http://lxr.mozilla.org/seamonkey/source/mailnews/base/public/nsIMsgDBView.idl#74
(In reply to comment #51) > 'Sort by Thread' was always a proxy value which translated to 'Threaded'+'Sort > By Order Received'. It's not a value that should be relied on, and if I'd > looked at this patch earlier, I would have said not to use '22' as the default > value for news. Setting it to 22 (0x16) simply reflects what was hardcoded previously, to make it fully backward compatible... viewFlags defaults to kThreadedDisplay for News folders and kNone for everything else - which is quite a sensible default, in my opinion. > If '22' behaves as the old Sort By | Thread menu used to > behave (xref bug 219620) then it's impossible to have a default view of > Threaded+By Date, which I prefer to Threaded+By Order Received. As far as I see, setting mailnews.default_news_sort_type to 18 (0x12) will do the trick - I just verified this with today's nightly build (20060815). Or am I missing something? > In fact, I'd go so far as to say there should be a third pref for both the > mail and news items explicitly controlling whether the default is Threaded, > Unthreaded or Grouped -- just as there are three group in the Sort By menu. Do you really think that's necessary (i.e. do defaults which differ from the one mentioned above really make sense)? It isn't a big deal to add support for configurable viewFlags, but OTOH having two additional prefs which nobody will ever change isn't really that useful...
(In reply to comment #53) > (In reply to comment #51) > > if I'd looked at this patch earlier, I would have said not to use '22' as > > the default value for news. > > Setting it to 22 (0x16) simply reflects what was hardcoded previously, to > make it fully backward compatible... > > viewFlags defaults to kThreadedDisplay for News folders and kNone for > everything else - which is quite a sensible default, in my opinion. I haven't looked closely enough to see how the values end up getting translated back into view settings. (In fact, I haven't yet even downloaded a build with your patch.) I just took a look and noticed that you were relying on a value that, in one or two patches that I was following before, was on its way towards being deprecated, and I wanted to say something before this progressed much further. It seems obvious to me that there are three orthogonal criteria for displaying a view, and these prefs should follow them. Right in the patch, I can see there's a "defaultViewFlags" member which I believe is what contains the threaded/unthreaded/group value. It may not be reasonable to have support in the pref for *all* the ViewFlags (I don't know what they all are) but for the ones controlled by the UI, it seems cleaner.
> I haven't looked closely enough to see how the values end up getting > translated back into view settings. The patch doesn't modify the current behavior, actually - it just allows you to set different defaults for new folders. What you seem referring to is the following code from nsMsgThreadedDBView::Sort(): // if sort type is by thread, and we're already threaded, change sort type to byId if (sortType == nsMsgViewSortType::byThread && (m_viewFlags & nsMsgViewFlagsType::kThreadedDisplay) != 0) sortType = nsMsgViewSortType::byId; ... which means that setting mailnews.default_news_sort_type to 22 (byThread) and using the default view flag for News folders (kThreadedDisplay) will be treated as "byId". The question is whether we should change this in mailnews.js, too - which effectively means changing the default previously hardcoded in nsNewsDatabase.cpp. In any case, I'm attaching an additional patch for making the default view flags configurable (through mailnews.default_view_flags and mailnews.default_news_view_flags) and am asking David for review. (Input validation is somewhat clumsy, since it might also allow "nonsense" values [e.g. kThreadedDisplay | kGroupBySort], but it's better than nothing, I think.) The patch changes the default for mailnews.default_news_sort_type to 21 ("byId"), which might or might not have side effects (David, can you shed any light on this?). What's still left open is the question of how (or if, for that matter) these additional settings should be accessible through the preferences UI. As there are now 6 values to be set (or 4, if we leave out the view flags), it's no longer feasible to put them under Advanced -> General). I will be attaching a new proposal where they appear on a separate tab.
Attachment #234006 - Flags: review?(bienvenu)
This is how the UI for setting these defaults could look like. Currently it only has those settings which are also exposed through the "View -> Sort" by menu, though support for additional view flags (kShowIgnored, kUnreadOnly, kExpandAll) could be added. Since it's very tedious to set these values manually (i.e. figuring out values from nsIMsgDBView.idl, possibly converting from hex to decimal, then going through the config editor), I would really like to see them accessible through the preferences UI. If we basically agree on how it should look like, I will prepare a corresponding patch. Should I ask Scott for a "review" of this screenshot?
Attachment #231238 - Attachment is obsolete: true
(In reply to comment #55) > What's still left open is the question of how (or if, for that matter) these > additional settings should be accessible through the preferences UI. How about this: instead of putting items in the Prefs, providing a menu command "make this view the default for [News|Mail]" (menu text changing depending on which type of folder is displayed). When user selects the menu item, copy the current views into the prefs.
Any more updates on this? Sorry, i'm a bit eager to get away from outlook/express for good and this is the only thing in the way for me.
Comment on attachment 234006 [details] [diff] [review] [fixed trunk and branch] Patch to make default viewFlags configurable (against trunk) looks good, thx.
Attachment #234006 - Flags: review?(bienvenu) → review+
Attachment #233353 - Attachment description: Patch v3 (backend changes only) → [checked in on trunk] Patch v3 (backend changes only)
Tb2.0a1 (20060912) please note that sort order config still does not apply to all threaded messages. for example, in this feed http://messages.finance.yahoo.com/Healthcare/Biotechnology_and_Drugs/rss?bn=5188 View->Sort by->Date, Ascending, Threaded setting will sort threads' first message correctly based on last message (w/ threading collapsed). but within the thread the selected sort order is not respected. it should simply follow whatever is selected, as a first cut - debatable whether there needs to be an exception (ie sort by different criteria within a thread). Tb has some problems keeping the thread together, with correct subject etc but that's a different bug. note also date/time in Tb differs from that on the yahoo site.
also, sort order in threaded messages is not respected upon entering a folder with new messages. for example, newsgroup m.d.apps.thunderbird. clicking on the date column to sort ZA and again to sort AZ will result in correct sort with threads with newest unread messages together in order at the bottom. should not be necessary to do this. it seems Tb uses the last order in the index without checking the pref and reindexing for new messages upon folder selection.
The IMAP METADATA Extension (which is bug 337330) has a serverside mailbox annotation that can hold preferences on how to initially sort and thread a mailbox. Maybe one day Thunderbird would read that, too.
Is there any reason the config setting can't be added to the 2.0 alphas? It doesn't seem likely to break anything major AFAICS. As it stands, I'm having to recompile 1.5.x regularly just to change the hardcoded sort order from ascending to descending and 3.0 far off from where I'm standing. Quite a few new users have asked about a way to change the default sort order very soon after using TB, it'd be great to have a way to do it in 2.0. Here's a quick sample of requests for this feature: http://groups.google.com/group/netscape.public.mozilla.mail-news/browse_thread/thread/271db01980f0ff9b/b2684999840cfc54?lnk=st&q=thunderbird+%22sort+order%22&rnum=1 http://groups.google.com/group/mozilla.support.thunderbird/browse_thread/thread/9ae74056c6956dae/a28dd201660afab6?lnk=st&q=thunderbird+%22sort+order%22&rnum=11 http://groups.google.com/group/netscape.public.mozilla.mail-news/browse_thread/thread/643fa53eff792c0c/bfe01debd02a9a9b?lnk=st&q=thunderbird+%22sort+order%22&rnum=12 http://groups.google.com/group/netscape.public.mozilla.mail-news/browse_thread/thread/8ff962284d7ed93/716a48ba2fe3de89?lnk=st&q=thunderbird+%22sort+order%22&rnum=14 http://groups.google.com/group/mozilla.support.thunderbird/browse_thread/thread/eef8cca03e30a0a3/b651fb4b714cc2c4?lnk=st&q=thunderbird+%22sort+order%22&rnum=24 http://blog.codefront.net/archives/2004/09/16/mozilla-thunderbird-changing-default-email-sort-order/ http://forums.mozillazine.org/viewtopic.php?p=2578214&sid=2d7c8fa5d2d99c6e5897e8803d76a566 thanks for considering, Jay
Some of the problems referred to above relate to bug 180604 where even when the sort order is manually set for a particular view it gets re-set.
David, could you check attachment 234006 [details] [diff] [review] in (on trunk)? Thoughts on getting theese in for 2.0?
yes, I'll land the stuff that's on the trunk on the branch, and look at landing the other stuff on the trunk and the branch.
https://bugzilla.mozilla.org/attachment.cgi?id=233353 landed on the 2.0 branch.
I notice it's not possible to set the default to "Order Received" (byNone, 17, 0x11) since it's less than byDate (18, 0x12). I often receive (non-spam) messages with incorrect timestamps far in the past or future, so I prefer to have byNone as my default; would it be reasonable to change the conditions in the two GetDefaultSortType() methods to allow this?
(In reply to comment #68) > I notice it's not possible to set the default to "Order Received" (byNone, 17, > 0x11) since it's less than byDate (18, 0x12). "Order Received" actually means byId (0x15), this should do the trick for you.
*** Bug 314643 has been marked as a duplicate of this bug. ***
Attachment #233353 - Attachment description: [checked in on trunk] Patch v3 (backend changes only) → [checked in on trunk branch] Patch v3 (backend changes only)
(In reply to comment #67) > https://bugzilla.mozilla.org/attachment.cgi?id=233353 landed on > the 2.0 branch. Branch still lacking attachment 234006 [details] [diff] [review], however.
OK, here's some off-the-cuff documentation: Prefs are named as follows; first three apply to Mail and RSS folders, the second three to Newsgroups. mailnews.default_sort_order mailnews.default_sort_type mailnews.default_view_flags mailnews.default_news_sort_order mailnews.default_news_sort_type mailnews.default_news_view_flags In about:config (Tools | Options | Advanced | General, Config Editor), you can enter "news._def" to filter out all the prefs but these. sort_order: byNone 17 byPriority 23 byLocation 29 byDate 18 * byStatus 24 byTags 30 bySubject 19 * bySize 25 byJunkStatus 31 byAuthor 20 * byFlagged 26 byAttachments 32 byId 21 ** byUnread 27 byAccount 33 byThread 22 byRecipient 28 byCustom 34 * = commonly desired values ** = by Order Received (?) sort_type: ascending 1 descending 2 view_flags -- the second group of values can be added to one of the first group to combine effects, with several limitations: Unthreaded 0 Threaded 1 Grouped 64 [mail only (?)] ShowIgnored 8 [news only] ShowUnreadOnly 16 ShowExpanded 32 [doesn't seem to work] ShowUnreadOnly will check the View|Threads|Unread menu; this will cause only unread items to be seen, but doesn't force a threaded view.
These settings are used when creating a new folder (including a feed subscription or newsgroup subscription), and when rebuilding an MSF file for the folder that doesn't exist or is hopelessly corrupt. If you use the Rebuild Index function (folder Properties), the existing settings for the folder are maintained.
(In reply to comment #74) > In about:config (Tools | Options | Advanced | General, Config Editor), you > can enter "news._def" to filter out all the prefs but these. Uh, no. That would be "news.default_". My bad.
Comment on attachment 234006 [details] [diff] [review] [fixed trunk and branch] Patch to make default viewFlags configurable (against trunk) Any interest in getting this in for 2.0? The companion patch is already there, I guess, but this second patch made the thing pretty usable for me.
yeah, I can land this for 2.0...
landed for 2.0
(In reply to comment #79) > landed for 2.0 Really? 2b2-0215 doesn't list the preferences mailnews.default_view_flags mailnews.default_news_view_flags
ah, thx, Mike, I didn't land the mailnews.js changes...
Comment on attachment 234006 [details] [diff] [review] [fixed trunk and branch] Patch to make default viewFlags configurable (against trunk) clearing approval flag, this already landed on the branch it looks like.
Not completely -- David hasn't followed up on comment 81 yet.
Well, I guess the second patch didn't make it in for 2.0. I haven't dug in to see if it's possible to use these prefs to configure for a default view with View | Threads | Threads with Unread (or Watched Threads with Unread) but my guess is that it's not. I think that's pretty much OK, but it would be a nice capability. Kaspar, I don't know how much more work you're planning on this bug. I thought the design you suggest for a UI is pretty straightforward, altho as I indicated in comment 74, I wasn't able to get Grouped to work in newsgroups (altho I only tested a little); if it doesn't, that radio-button should be left off. But I don't know if the UI would be accepted as part of the TB product; perhaps you could develop an extension for it instead.
The backend for this is fixed, isn't it? Should this be closed, or are we still waiting for some more work?
Does this actually work in V220.127.116.11 yet because every time I have to alter or create a new imap account TB insists on listing the contents of my folders sorted by Date and Descending and Unthreaded. I want all my 40+ folders sorted by Date, Ascending and Threaded I've tried a user.js file: user_pref("mailnews.default_sort_order","18"); user_pref("mailnews.default_sort_type","1"); user_pref("mailnews.default_view_flags",1"); But it doesn't work. The documentation in this report seems to list the settings for .default_sort_order and .default_sort_type in a reversed order from my actual V2.0.014 settings. See comment #74 and mailnews.default_view_flags is also still missing from V18.104.22.168 Can we get this fixed?
Seems to work in TB 3a1. It also works on my TB 22.214.171.124 - I had to delete the local file structure of the imap account after starting TB all mails in all imap folders were sorted descending (as I wish). Maybe you need to remove the index-files (.msf) Christian
lol. and then to think this bug has been open since 2001. In 3 years it's time to celebrate its 10 year anniversary!
Yes, you need to remove the old .msf files, but this should be working on the trunk now - this has all been landed on the trunk, so I'm marking this fixed. We could use a new bug for whether we want to have a UI for these settings...
I thought that 'configurable' implied this! Either that or my very old bug, marked as duplicate, doesn't really qualify as duplicate. So my say is to keep this bug open until 'configurable' has been made 'configurable to the end user'. After all... that's what most of us want.
(In reply to comment #90) > Yes, you need to remove the old .msf files, but this should be working on the > trunk now - this has all been landed on the trunk, so I'm marking this fixed. ->FIXED
Assignee: nobody → mozbugzilla
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Summary: Sort order for mail/news not configurable by default → Sort order for mail/news not configurable by default (back-end part)
Target Milestone: --- → mozilla1.8.1
Guys seriously? This problem has been around since 2006… I am a big fan of thunderbird… but I like is less and less every day. I receive about 4000 emails everyday and have about 15 imap folders I am subscribed to… When I upgrade a new version of Thunderbird all my settings are getting reset and there is now easy way to sort all the folders… even though the config… This issue is not fixed and I don’t understand why it takes 4 years to fix it….
Also, since mailnews.default_view_flags is not there anymore what is replacement?
It is there, in 3.0 - we just added a new pref that only controls news groups. We did not remove mailnews.default_view_flags.
I'm not seeing mailnews.default_view_flags in my list in 2.0 - maybe that's why we think it's missing. I too am completely frustrated by this. I've converted all my mailer to sort messages with the newest at the bottom - but it's sub-optimal and I shouldn't have to. Here's the scenario in t-bird. I click on the "Date" tab twice to change the sort order to newest at the top. Later I need to sort by Subject, or Sender or whatever. When I click on "Date" it reverts to oldest at the top. This is simply goofy. And so I'm going to try once again to move to Evolution, which I consider a step down, but if it will do what I want - why not. How can a problem that not actually resolved or fixed be marked as such?
Are you using 2.0 or 3.0? I know I see view_flags in the config editor in 3.0
2.0 as I noted. Your previous comment was vague - I couldn't tell if you were saying it was there in 3.0, or it was there and that in 3.0 "we just added a new pref..." Turns out Evolution has the same goofiness - the sort order for a column is tossed as soon as you use a different column (e.g., sender) and come back. I've tried the sort order default - and I'm trying to find the .msf files to delete (though I tried that before as well).
In the config editor I see an entry for "mailnews.default_sort_order" which is set to 1. Could there be provided an alternate number that would make the default sort order for new folders "Order received + Descending", or whatever default sort order one might want when a new folder is created or the sort order reset to the default? And why is this marked Resolved/Fixed? Recent comments seem to suggest it should be re-opened.
Okay, based on Comment #74 and what I find in the configuration file it would appear he got it reversed and that it should be: sort_type: byNone 17 byPriority 23 byLocation 29 byDate 18 * byStatus 24 byTags 30 bySubject 19 * bySize 25 byJunkStatus 31 byAuthor 20 * byFlagged 26 byAttachments 32 byId 21 ** byUnread 27 byAccount 33 byThread 22 byRecipient 28 byCustom 34 * = commonly desired values ** = by Order Received (?) sort_order: ascending 1 descending 2
I had taken to some monstrous hacks in earlier versions of TB to get what I liked as a default (descending by date), but now that this patch is in, it got easier to achieve what I was looking for. So I wrote up an addon that uses this fix to help the too-casual-for-config-editor end user make changes: https://addons.mozilla.org/en-US/thunderbird/addon/57219/ It would certainly help to have an interface for sorting inside TB proper, but this bug is apparently for just the function, not the UI. Maybe a new one should be opened to cover the interface for this if it hasn't been already.
This bug is marked as "fixed", don't know why as you have to go to about:config and in some cases change every folder. I would like the "proposed extension" graphic, is there any way to re-open the bug?
I also don't see, why this is "fixed". And I would also say that clicking on the date column in the default setup should jump to newest email (and sort by date descending). And in the standard setup I don't see any easy way to define this.
For those asking that this bug to be reopened to address the problem of columns set to use descending sort order (e.g. Date) resetting to ascending sort when clicking on another column temporarily and then back, note that bug 1258001 (2016-03-18) now covers this enhancement request. Unfortunately there's apparently been no coding yet; hopefully there will be, since having to click twice on date columns every time is ridiculous and irritating, and there appear to be no add-ons addressing this.
You need to log in before you can comment on or make changes to this bug.