515316 - Retention policy settings of folders are altered to an other folder's setting when "Use my account settings" of a different folder is changed

Status: RESOLVED FIXED

(MailNews Core :: Backend, defect, P1)

Description

[WADA:World Anti-bad-Duping Agency]

[Build Id]
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090907 Shredder/3.0b4pre

"Use my account settings" of retention policy of a folder is changed to Inbox's setting when "Use my account settings" of Inbox is changed.
This was observed while I tried to see Tb trunk's behaviour for Bug 515037.

a) Above is observed on all of POP3(Non Global Inbox use), IMAP, "Local Folders".
b) Upon folder creation, "Use my account settings" looks to be inherited from
   "Use my account settings" of Inbox of the account.
c) Problem doesn't seem to occur on folder of "Default Account".
d) Problem is observed after restart of Tb.
e) Once retention policy setting of a folder is changed with "Use my account settings"=unchecked, problem doesn't seem to occur, even after change back to original/default setting.

Data/Control block for retention policy is not cleanly initialized upon folder creation?

[Steps to reproduce]

1. Create a new profile
2. Create first account(default account, POP3)
   => "Local Folders" is created too. 
3. Create Inbox, Sent etc. at "Local Folders"
4. Create some accounts(POP3, IMAP. Non default account)
5. Create some folders under each account.
6. View "Use my account settings" of Inbox and some folders under an account.
7. Change "Use my account settings" of Inbox
   (Checked=>Unchecked, Unchecked=>Checked)
8. View "Use my account settings" of folders.
   If Checked=>Unchecked at step 7, Unchecked.
   If Unhecked=>Checked at step 7, Checked.

Comment 1

[rsx11m]

For Gmail IMAP subfolders, changing the status of "Use my account settings" in one folder changes it for all subfolders, but apparently not for the Inbox.

Was this observed already before the fix for bug 499306 checked in?
I've just noticed that bug 515037 was filed against 2.0 branch.

Bug 472203 may be related or a possible manifestation of this.

Comment 2

[WADA:World Anti-bad-Duping Agency]

Checked with next build(bug 499306 is fixed on 9/06)
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090902 Shredder/3.0b4pre

1. Folder creation(POP3):
   "Use my account settings"=Unchecked. Always default(never delete) was set. 
2. Folder creation(Local Folders):
   "Use my account settings"=Checked. => bug 515037 is reproduced with 9/02 build.
3. "Use my account settings" change of a folder, including Inbox:
   No other folder's "Use my account settings" was changed.

Comment 3

[rsx11m]

Similar reports: bug 516473, bug 518571.

Comment 4

[Mark Banner (:standard8)]

I wonder if this is a side-effect of making the folders inherit the column settings.

Comment 5

[Kent James (:rkent)]

In Henrix, a user noted the severity of this problem when she changed the retentions settings for her junk folder to delete most messages, and found that ALL of her messages in all folders were deleted.

This is a critical bug that needs to block.

Comment 6

[David Ascher (:davida)]

From latest comment, I'd agree.

Comment 10

[Andrew Sutherland [:asuth] (he/him)]

(In reply to comment #4)
> I wonder if this is a side-effect of making the folders inherit the column
> settings.

No.  That logic just peeks at the dbFolderInfo for a folder, and since the Inboxes never get closed we should not be triggering anything (since they should always be already open) and so there should be no behavioral change at all.

Comment 11

[rsx11m]

Note that some of the related reports are not restricted to the Inbox,
changing the settings in a Junk folder has been reported to cause similar effects (comment #5).

Comment 12

[WADA:World Anti-bad-Duping Agency]

Changing initial "Inbox" in bug summary to "other folder", to avoid confusion or mis-leading.

Comment 13

[asledzik]

I'think the title should be slightly different - because the change of retention policy applies to ALL of the other folders

Comment 14

[WADA:World Anti-bad-Duping Agency]

Changing bug summary slightly, according to comment #13. I'm not native English speaker. Please modify bug summary to appropriate one.
Sorry to "Threaded view" lovers for frequent bug summary change.

Comment 15

[Dan Mosedale (:dmosedale, :dmose)]

Mark, would it make sense for you to take a run at this, since you've poked at related stuff (bug 499306) in the past?

Comment 16

[David :Bienvenu]

I think it makes more sense for me to look at this.

Comment 17

[Kim Xupei]

I experienced today a similar issue to the one described in comment #5. And I am able to reproduce it. In one sentence: changing the retention policy of a subfolder also immediately applies that change to the Inbox folder.

[System]: OSX 10.4.9, PPC, system language: English.

[Thunderbird ID]: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4

[Steps to reproduce]:
1. Select any sub-folder, located under "Local Folders > Inbox".
2. Go under "Edit > Folder Properties > Retention Policy".
3. Uncheck the box "Use my account settings".
4. Check the button "Delete all but the most recent N messages".
5. Click the OK button and observe.

[Actual result]:
All messages but the N most recent ones are deleted, not only in the selected folder, but also in the Inbox, and in all or most other subfolders. When verifying the folder setting of the Inbox, I see that it has changed from "Use my account settings" to the setting applied at step 4.

[Expected result]:
The setting should only apply to selected folder, not to the main Inbox.

[Note]: I experienced this issue after upgrading from the previous Thunderbird Beta, 3.0b3.
Also, is seems that the new setting (set in step 4) applies to some, but not to all other sub-folders. I'm currently not able to figure out what rule is applied here. Possibly it does not apply to *all folders that had any sort of custom retention policy*, while the folders that never had any specific retention policy (where "Use my account settings" was checked) are affected.

Comment 18

[rsx11m]

The previous comment confirms what was reported in bug 516473, thus that has a wider impact than the account settings checkbox and the Inbox. As for the subfolders, I had noticed that as well, but changes were restrained within the set of subfolders and didn't go beyond that to other folders.

I'm adjusting the summary (again) to reflect that all settings may change.

Comment 19

[Susanne Jaeger]

I have the same/ a similar problem with SM2 Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5pre) Gecko/20091008 SeaMonkey/2.0pre Changing the retention policy for one subfolder spread around to other folders and resulted in data loss.

Comment 20

[David :Bienvenu]

The problem is that when a folder falls back on the server defaults, it returns that retention settings object to the front end, which pokes at it directly, thus changing the server defaults, including potentially the "use server defaults" field, which it could set to false, if the user changes a folder. So the main fix will be to clone the incoming server settings, and to make the server settings object always get set to "use server defaults".

Comment 21

[David :Bienvenu]

Attachment: don't cache server settings

If we don't cache the server settings, then the caller can't crunch our cached copy, and things are much happier.

Comment 22

[[e-mail]]

Comment on attachment 405334 [details] [diff] [review]
don't cache server settings

This will help for when the UI eventually goes straight to GetXXXValue and skips this step :-)

Comment 23

[David :Bienvenu]

fix checked in.

Comment 24

[Susanne Jaeger]

solved my problems in Seamonkey. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5pre) Gecko/20091009 SeaMonkey/2.0pre - Build ID: 20091009234639

Comment 25

[rsx11m]

I can no longer reproduce this with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5pre) Gecko/20091010 Shredder/3.0pre either. As a positive side effect, the fix here also seems to have resolved the problem in bug 499303.