Closed Bug 476217 Opened 15 years ago Closed 14 years ago

archive folder setting should not be per-identity

Categories

(Thunderbird :: Mail Window Front End, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: tuukka.tolvanen, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: useless-UI)

archive folder setting should not be per- sender-identity, it ...kinda makes no sense at all, as far as I can figure. It should probably be per storage account, but since that hierarchy doesn't really exist in the pref tree, per incoming account. Preferably hidden for pop accounts whose storage is deferred (e.g. to "local folders")
I think the original coders found it much easier to use the existing infrastucture for setting up default folders in the account settings ui, but I agree it's really more of a per incoming server/account thing than an indentity thing.

We should be using the local folders account/the deferred to account as the default for deferred accounts - I thought the code was doing that already...
useless-ui in identity manager, although I suppose it could be just hidden as approriate regardless of where the pref sits in the pref tree. Deleting a default identity is probably uncommon but I expect the archive prefs for the account would be magically lost with it, dunno if there are any other cases of potential fail available. If this is fixed it would be good to do it before a release to avoid having to deal with migration.
Flags: blocking-thunderbird3?
Keywords: useless-UI
I don't know if it's doing that now, but if the archiving code looks at to which identity the the mail was addressed, there could be perfectly valid use cases for it. E.g. a work mail and a private mail identity, where you'd likely not want to mix the archives.
OS: Linux → All
Hardware: x86 → All
a skim of http://mxr.mozilla.org/comm-central/source/mail/base/content/mailWindowOverlay.js?mark=1067,1093#1031 tells me it groups msgs into batches by sourcefolder+destinationfolderleafname, so each batch may include msgs to different reply identities; a batch of msgs is moved into the hierarchy indicated by the reply identity found for the first msg of the batch ...so afaict it isn't implementing reply identity based archive targeting correctly, but rather selecting the target for each monthful based on a random message in the monthful.

As for whether it should ...I could argue that if you want to keep work and private mail separate then they would already be separate before archiving. Of course that separation could be folders-within-one-account which separation would not be reflected in archives as of now; in that case I think a more flexible solution would be to mirror folder structure within the archives so that the archives organization reflects the organization set up by the user, rather than limiting the archives separation to the more subtle identities only.
I can see that alternative models might make sense, but I don't think we'd block on this.
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
I just found this issue, because I had the problem, that TB always created the archive in my IMAP mailbox (which does not work in my case, because not subfolders are allowed), despite of the account settings. I thought it was a bug in the archiving feature until I found this entry. Of course, the solution was, that I changed the default setting for the location only for the default identity.
So, in short: I think, there might be valid use cases for this as well, but right now it is just confusing and difficult to find out, what "the problem" is...
I hate to have the UI code drive these decisions, but it definitely seems like the Archive folder picker belongs with the other special folder pickers in account settings. I suppose that code could poke server prefs instead of the identity prefs.
This relates to a higher-level problem of there being no definitive documentation of what the conceptual model is for Accounts and Identities. The UI and the config structure do not match. The actual behavior is a bit of a mystery for users because there's no obvious association of a message to an identity. Since "Archive" can be a per-message arbitrary user action, there needs to be some obvious way for the user to see and set the classification of the message that controls its archiving. 

I think the title of this bug proposes the *wrong* solution to the problem, although it would be the easiest way to get predictable behavior. Accounts are primarily descriptions of message stores, Identities are primarily descriptions of functional roles. The UI makes Identities subordinate to Accounts, but the config structure *and informed reason* do not, and even when an Identity is strictly limited to messages stored in one Account, mixing up the messages of all of an Account's Indentities is hostile to how Identities are used. 

I think the *correct* solution is to fix Identity support so that every message has an owning Identity, with a clear UI for seeing and setting that relationship. Filters should be able to set it, folders should have an explicit default Identity , and TB should make some attempt to parse new message headers for a suitable owning Identity. 

A middle ground would be to make the archive folder an attribute of a Folder. That's the Outlook approach, and users may be most comfortable with it. If Identities are strictly subordinate to Accounts, the functional different between binding an archive folder to a Folder or to an Identity (with Folders having default Identities) is minimal.
With bug 517514 having changed mail.server.*.archive_granularity now to mail.identity.*.archive_granularity, this bug is basically a won't-fix?
fixed by bug 517514 (or dup, I don't care...)
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Depends on: 517514
You need to log in before you can comment on or make changes to this bug.