Open Bug 1315623 Opened 8 years ago Updated 4 months ago

archive function sometimes creates year-based folder even if disabled in options

Categories

(MailNews Core :: Backend, defect)

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
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.90 Safari/537.36 Steps to reproduce: Selecting one or a few messages and pressing A to archive them. The account is configured to have only a single "Archive" folder. This is a plain IMAP account. No google mail etc. Actual results: Most of the time, the mails are put correctly inside "Archive" without a subfolder, but in some cases, a year-based subfolder is created. Expected results: There should never be a year-based subfolder if this option is enabled. This bug exists since several years and only appears on some computers but I cannot find any condition that triggers it.
bug 1162932 reports similar behavior which was a result of different settings between identities. (bug query https://mzl.la/2iAYxhb )
Blocks: 473212
Component: Untriaged → Backend
Product: Thunderbird → MailNews Core
Version: 45 Branch → 45
Severity: normal → S3

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 into archive\year and sometimes into archive 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.

Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → All
Hardware: Unspecified → All
See Also: → 1162932
Duplicate of this bug: 1664960
Duplicate of this bug: 1842363
Duplicate of this bug: 1847425
Keywords: ux-control, ux-trust

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.

User Story: (updated)

@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 in tools > settings or in the Local folders account, which lacks archive 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…

(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.

(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.

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.

(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.

User Story: (updated)

(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 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.

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 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". 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...

You need to log in before you can comment on or make changes to this bug.