archive function sometimes creates year-based folder even if disabled in options
Categories
(MailNews Core :: Backend, defect)
Tracking
(Not tracked)
People
(Reporter: languitar, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: ux-control, ux-trust)
User Story
workaround in comment #7 and comment #12
Comment 1•8 years ago
|
||
Updated•2 years ago
|
I can confirm this behavior. It seems to happen seemingly at random.
Can reproduce on TB 115.6.1 @ Win10-64bit.
-
reproducible: sometimes
Just as reported by the other users in comment #2 and comment #0, my messages are also sometimes archived intoarchive\year
and sometimes intoarchive
directly.
So far I have been unable to determine on what the outcome depends. -
All my mail accounts are POP3.
-
I don't have separate archive settings for any identities (i.e. all identities share the account's archive settings). So the problem is different from bug 1162932 mentioned in comment #1.
See duplicate bugs for more bug confirmation, screenshots and logs.
This is a difficult area. For each message to be archived, the system tries to determine the identity for the message, so it can apply the correct archive settings, see:
https://searchfox.org/comm-central/rev/2f8de405cccd35da474d12d9332a4bce31edd818/mail/modules/MessageArchiver.sys.mjs#111
The code to determine the identity for a given message is rather tricky:
https://searchfox.org/comm-central/rev/2f8de405cccd35da474d12d9332a4bce31edd818/mail/modules/MailUtils.sys.mjs#671
One would have to see where it fails in the particular "random" cases.
If the identity can't be determined, the default value for "granularity" (0=single folder, 1=yearly) is taken from pref mail.identity.default.archive_granularity
, default 1: yearly. Example: A message from Mickey to Goofy which was BCC'ed to a user will be archived to a yearly folder since neither Mickey nor Goofy are configured identities.
If you set that pref to 0, you won't see yearly folders again.
@Francesco: Great find!
I think this would prevent the problem from occurring:
- If the identity cannot be determined, use receiving email account's archive options (but I think this is done already, no?).
- Expose
mail.identity.default.archive_granularity
as a UI setting intools > settings
or in theLocal folders
account, which lacksarchive options
.
I gladly set mail.identity.default.archive_granularity
to 0
and I do hope to never ever see yeary folder again...
I think that this option should be exposed better. And maybe it's default switched?
@chrizilla
If the identity cannot be determined, use receiving email account's archive options (but I think this is done already, no?).
Well, if it did then we wouldn't have random yearly archived messages…
Comment 10•8 months ago
•
|
||
(In reply to wojtek from comment #9)
Well, if it did then we wouldn't have random yearly archived messages…
Not necessarily. Maybe TB didn't know to which mail account those yearly archived messages belonged.
Go to message list > table view and enable the account column.
For 99% of my messages, the account column displays the corresponding mail account, but for 1% of my messages, the column says Local Folders
(as if the messages were imported from .eml files for example, but they weren't). Maybe this is a separate bug. These could be the messages, where no ID can be determined, thus using mail.identity.default.archive_granularity
.
Comment 11•8 months ago
•
|
||
(In reply to Francesco from comment #7)
Yes, my mail.identity.default.archive_granularity
had a value of 1.
This is really weird: Filtering for archive_granularity
, the config editor shows me mail.identity.id7.archive_granularity
has a value of 1 (yearly) whereas all other identities have a value of zero. Investigating further, I noted the email address in mail.identity.id7.useremail
and looked it up in account settings > account > manage identities > select identity > edit > copies & folders tab > archive options
(I really the settings hierarchy needs to be streamlined because at sublevel 7 this is really buried deep down ...). But in the archive options
overlay window, a single folder
is selected in the radio button. So the UI doesn't seem to match the pref in the config editor ... weird.
May this can also explain some of the sightings above ?
I checked my archive
folder again and the yearly archived messages all belong to mail.identity.id7
. I should have noticed that right away. So in my case, in order to solve the bug, it would have to be determined, why the UI doesn't match the setting displayed in the config editor.
I don't know if that explains the sightings in comment #0 and comment #2 or is a separate issue causing the same symptoms.
Comment 12•8 months ago
|
||
bugfixing-strategy workaround |
IMHO, the archiving options are a mis-design. Usually, mail.identity.default.what_ever
is a "template" for mail.identity.idNN.what_ever
, so when identity idNN is created, it copies the default. I haven't see a case where mail.identity.default.what_ever
would be applied for things that aren't related to an identity or the identity can't be determined.
As for comment #8. There is no "receiving email account's archive options", they are purely identity based. And the trouble starts when a message can't be related to any identity. What you mean is that when an identity cannot be determined, the setting of the default identity of the incoming server to which the folder belongs should be used. Changing the behaviour of getIdentityForHeader()
to cater better for archiving purposes may break other usage of the function.
If you look at the function getIdentityForHeader()
https://searchfox.org/comm-central/rev/2f8de405cccd35da474d12d9332a4bce31edd818/mail/modules/MailUtils.sys.mjs#671-722
and it's callers, you can see that it's mostly called with only one parameter. That also doesn't appear to be right, since the hint
depends on the type.
Looking at the code again, maybe setting mail.identity.default.archive_granularity
is also not a sufficient workaround. getIdentityForHeader()
calls getBestIdentity()
and that will return an identity. So as long as there is an identity in the system that has granularity set to 1, it might be picked.
So maybe the workaround is: In the config editor search for archive_granularity
and set all the values to 0.
You need to get a developer interested in this. Maybe the best approach is not to call getIdentityForHeader()
and instead develop a simpler strategy to determine the archive folder based on the idea in the second paragraph.
Comment 13•8 months ago
•
|
||
(In reply to Francesco from comment #12)
As for comment #8. There is no "receiving email account's archive options", […]
What you mean is […]
What I meant is:
Let's say a user has a mail account named "my mail account" and only the default ID is configured: superuser1@domain.tld
. No additional IDs have been added via manage identities
. But the user has an alias (same login) superuser2@domain.tld
provided by the email provider. So if the user receives an email for superuser2@domain.tld
, the receiving account is displayed in the message list account
column as "my mail account" (although no ID is configured for superuser2 !). For archiving this message, TB should use the "receiving email account's archive options", i.e. account settings > "my mail account" > copies & folders > archive options
.
As said in comment #8, "I think this is done already" judging on my tests.
Comment 14•8 months ago
|
||
(In reply to chrizilla from comment #10)
(In reply to wojtek from comment #9)
Well, if it did then we wouldn't have random yearly archived messages…
Not necessarily. Maybe TB didn't know to which mail account those yearly archived messages belonged.
Go to message list > table view and enable the account column.
For 99% of my messages, the account column displays the corresponding mail account, but for 1% of my messages, the column saysLocal Folders
(as if the messages were imported from .eml files for example, but they weren't). Maybe this is a separate bug. These could be the messages, where no ID can be determined, thus usingmail.identity.default.archive_granularity
.
Unfortunately I already corrected the yearly folder mess, so I have no way to verify it. However, after changing the setting it seems to stop (at least for me)(In reply to chrizilla from comment #13)
(In reply to Francesco from comment #12)
As for comment #8. There is no "receiving email account's archive options", […]
What you mean is […]What I meant is:
Let's say a user has a mail account named "my mail account" and only the default ID is configured:superuser1@domain.tld
. No additional IDs have been added viamanage identities
. But the user has an alias (same login)superuser2@domain.tld
provided by the email provider. So if the user receives an email forsuperuser2@domain.tld
, the receiving account is displayed in the message listaccount
column as "my mail account". For archiving this message, TB should use the "receiving email account's archive options", i.e.account settings > "my mail account" > copies & folders > archive options
.
Hm... indeed I'm in such situation! I have my main mail wojtek@<domain1> but also addd <domain2> and <domain3> and all incomming emails end up in the same inbox...
Description
•