1295994 - (Archive_options_settings-inheritance) Archive options settings inheritance (in newly created identities) is confusing

Status: UNCONFIRMED

(Thunderbird :: Account Manager, defect)

Description

[marty]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160726073904

Steps to reproduce:

Archive two mails with different recipients that are both contained in the same source (sub)folder whilst the keep folder structure option during archiving is switched on.

(see for more information: https://bugzilla.mozilla.org/show_bug.cgi?id=668215#c36 )


Actual results:

The mails get archived to two different archive folders. One went to the appropriate archive subfolder, the other to the 2015 archive folder. Both mails are practically identical (even in terms of headers) with the exception of the recipients.



Expected results:

Both should have gone to the configured archive (sub)folder (not the 2015 archive folder).

Comment 1

[marty]

This bug is especially annoying when archiving multiple subfolders. Lots of mails get thrown onto one pile in the 2015 archive folder. Your year worth of sorting is then lost!

Comment 2

[marty]

I learned that archiving behavior can be set in two ways:

1.) Account Settings > [pick account] > Copies & Folders > Archive options...

2.) Account Settings > [pick account] > Account settings > Manage Identities > [pick identity] > Copies & Folders > Archive options...

The two options are confusing. When one sets the archiving behavior for the account and doesn't make specific settings for identities under that account, than one would expect the identities to inherit the behavior from the encapsulating account unless when set specifically for an identity.

Nowadays one can also edit the from address on a per message basis. What will happen if somebody sends a reply to such a message? Where will it be archived?

Comment 3

[marty]

Additional information for reproduction of the bug:

Beforehand:
Start out with an account with multiple identities.
Set archiving behavior via Account Settings > [pick account] > Copies & Folders > Archive options...
Configure a non default directory to Archive in.

Comment 4

[marty]

Workaround: When one has multiple identities then bypassing Archive functionality altogether and moving emails by hand is more easy than configuring archiving options on a per identity basis.

Comment 5

[marty]

BTW I have 51 email identities.

Comment 6

[bintoro]

Sooo... Are you saying that, when archive options are correctly configured on a per identity basis, the settings are nevertheless occasionally not respected?

Or is this bug now about how confusing it is for archive options to reside at the identity level? If so, then that is not currently clear at all, and I would advise to reword the bug summary line.

Comment 7

[marty]

(In reply to bintoro from comment #6)
> Sooo... Are you saying that, when archive options are correctly configured
> on a per identity basis, the settings are nevertheless occasionally not
> respected?
I did not test that. It will take me a while to change settings for 51 identities and gather telemetry on that.
I did test what happens to a received email with a TO-address-field that does not have an identity coupled to it in the receiving account. It is archived according to the account archive settings. That is exactly the behavior that I would expect for identities where no archive options have been set for.

It seems like a minor change to fix this.
> 
> Or is this bug now about how confusing it is for archive options to reside
> at the identity level? If so, then that is not currently clear at all, and I
> would advise to reword the bug summary line.

It is the latter one.
I set archive options per account.
I wasn't aware of the possibility to also set archive options per identity.
I would expect the account settings to be the default for all identities in that account.
Manually setting separate archiving options for 51 identities, when one wants to change the archive location, is very troublesome.

Maybe this should be a feature enhancement and not a bug, but I don't know what is specified behavior in this case and therefore can't make the call on that. Because it's counter intuitive I opted for a bug.

Comment 8

[Wayne Mery (:wsmwk)]

see https://mzl.la/2ie9atE

Comment 9

[marty]

I retested for 51 email identities (see comment #7). The results are:
when archive options are correctly configured on a per identity basis, the settings are respected.

The problem boils down to the following:
Pre: Archiving behavior is only set via:
Account Settings > [pick account] > Copies & Folders > Archive options...

When a new email identity is created after that, then its distinct Archive options are copied from the account settings (Account Settings > [pick account] > Copies & Folders > Archive options).
When these global account archive options are later on changed, then the archive options for the identities (which have never been explicitly set) stay the same.
This is confusing.
I would presume that when archive options have not been set explicitly for an identity, then it should inherit its behavior from the account settings.

I hope this helps (I had to change 51 identities by hand to change the archive location).

Comment 10

[marty]

When I think about it, then the "Account Settings > [pick account] > Account settings > Manage Identities > [pick identity] > Copies & Folders > Archive options..." (identity configuration) should have 2 states with the following behavior:

1. Unconfigured: use effective configuration from "Account Settings > [pick account] > Copies & Folders > Archive options..."
2. (Manually/explicitly) Configured: stick with the explicitly made "Account Settings > [pick account] > Account settings > Manage Identities > [pick identity] > Copies & Folders > Archive options..." configuration

Comment 11

[Martin Kimmerle]

(In reply to marty from comment #10)
> When I think about it, then the "Account Settings > [pick account] > Account
> settings > Manage Identities > [pick identity] > Copies & Folders > Archive
> options..." (identity configuration) should have 2 states with the following
> behavior:
> 
> 1. Unconfigured: use effective configuration from "Account Settings > [pick
> account] > Copies & Folders > Archive options..."
> 2. (Manually/explicitly) Configured: stick with the explicitly made "Account
> Settings > [pick account] > Account settings > Manage Identities > [pick
> identity] > Copies & Folders > Archive options..." configuration

I fully agree there should be some settings-inheritance. Maybe there's a more general solution than you're describing. There are many settings in the "Identity Settings" window. Why not allow to switch between "default" and "identity-specific" settings for more than just only "Archive options"? I don't know at which granularity. For instance, there could be said switches (selection between "default" and "identity-specific") for each tab (Copies & Folders, Composition & Addressing, etc.), or even for each option.

In any case, newly created identities should inherit the account-specific default settings. When the account-specific default settings are changed, all identities inheriting the default behavior should be changed at the same time.

Thank you marty for creating this bug report. However, you should change the title to reflect the actual problem.

Comment 12

[marty]

Changed title from:
"two mails in the same subfolder are archived to two different archive folders"
to:
"Archive options settings-inheritance"

Comment 13

[Wayne Mery (:wsmwk)]

Does the new subject capture what you are seeing?
(Let's keep version at the initial setting)

Comment 14

[marty]

(In reply to Wayne Mery (:wsmwk) from comment #13)

Does the new subject capture what you are seeing?
(Let's keep version at the initial setting)

Uhm, the subject doesn't cover the load completely. The confusion occurs when the super setting is changed, but the sub settings stay the same for identities where archiving options have never been explicitly set.

I did retest in version 68 and the problem still exists there so why keep it on branch 45? Will a fix migrate to the head branch?

Comment 15

[Wayne Mery (:wsmwk)]

(In reply to marty from comment #14)

I did retest in version 68 and the problem still exists there so why keep it on branch 45?

Because we want version to reflect when the issue was first reported.

Will a fix migrate to the head branch?

we don't have a fix, so impossible to say.