511310 - make Smart Folder mode the default

Status: RESOLVED FIXED

(Thunderbird :: Folder and Message Lists, defect)

Description

[Dan Mosedale (:dmosedale, :dmose)]

One of the as-yet-untracked blockers from the our recent powwow in Vancouver is to make Smart Folder mode the default.  Here's a bug for that.

Comment 1

[David :Bienvenu]

I have a patch for this, but this reminds me that I never dealt with the issue of a profile with just a single mail account - I could either make smart folders handle that case by falling back to "all folders" behavior or by not showing the account level or the smart folders.  With time so tight, I'm tempted to go with the first solution. But, for the new profile case, I'd want it to actually be in smart folders mode, but just behave like "all folders" with a single account.

Comment 2

[David :Bienvenu]

Attachment: proposed fix

Default to smart folders on upgrade and new accounts, but make smart folders fall back to the "all" generator if there isn't more than one inbox.

Comment 3

[Magnus Melin [:mkmelin]]

Comment on attachment 396550 [details] [diff] [review]
proposed fix

>+    // Smart mode only makes sense if there's more than 1 incoming mail account,
>+    // so check for that and fall back to "all folders" if we don't find a 2nd.
>+    let accounts = gFolderTreeView._sortedAccounts();
>+    let numMailAccounts = 0;
>+    for each (account in accounts) {

for each (let account in accounts) {

r=mkmelin with that

Comment 4

[David :Bienvenu]

I'd like to fix bug 492922 before landing this patch, and address Magnus's comment.

Comment 5

[David :Bienvenu]

fix checked in - I'm fairly comfortable that the fix for 492922 is going to land soon.

Comment 6

[Peter Lairo]

Smart Folders disables the "Remove deleted messages..." button for IMAP + Mark as Deleted" accounts. This makes Smart Folders unusable for these users. :-(

Is something being done about that? Why wasn't this bug made dependent on fixing that first?

Comment 7

[Peter Lairo]

Since this bug was fixed but its blocker bug (bug 516220) is not fixed, the blocker bug's urgency should be elevated.

Comment 8

[Mark Banner (:standard8)]

(In reply to comment #7)
> Since this bug was fixed but its blocker bug (bug 516220) is not fixed, the
> blocker bug's urgency should be elevated.

That doesn't hold true especially as you filed that bug after this one was fixed.