As a probably regression from bug 436630, I cannot change the folder used for moves of junk messages. STR: 1) Create a new profile. Add a single IMAP account. 2) On both the IMAP account, and the Local Folders account, enable adaptive junk controls and "Move new junk messages to" and choose the default ('"Junk" folder on' and then the account name). 3) Go to the IMAP account. Change the "Junk" folder on ... to Local Folders. Press OK. 4) Re-enter the Account Settings dialog. Expected Results: '"Junk" folder on' points to Local Folders Actual result: '"Junk" folder on' continues to point to the original value (for the IMAP account). The bug does not appear in a 2008-06-15 nightly, but does appear in 2008-06-18
Created attachment 332625 [details] [diff] [review] The fix This doesn't seem to be getting any love, so let me give it a shot. I want to test another day before review though.
Assignee: nobody → kent
Status: NEW → ASSIGNED
Created attachment 333712 [details] [diff] [review] Patch for review I should point out that this patch restores using the long folder name (Junk on Local Folders) in selections, which is the pre-bug 436630 behavior, but is now inconsistent with other parts of the account manager which is using the folder name only. I don't know why it was changed, and I prefer the old style. I think the other folder selections should also be changed to revert to using long names as they did before.
Comment on attachment 333712 [details] [diff] [review] Patch for review >+ var longFolderName = document.getElementById("bundle_messenger") >+ .getFormattedString("verboseFolderFormat", >+ [folder.prettyName, folder.server.prettyName]); >+ var folderName; >+ if (folder.isServer) >+ folderName = folder.prettyName; >+ else >+ folderName = document.getElementById("bundle_messenger") >+ .getFormattedString("verboseFolderFormat", >+ [folder.prettyName, folder.server.prettyName]); Why two completely different looking pieces of code?
(In reply to comment #3) > Why two completely different looking pieces of code? > The first section initializes the "Other" field which is always a folder, not a server. Hence the name is always a long name, and I don't need to support the server option. The second section updates either the folder or account field, so it needs to support a server (with no long name) as well as a folder (with a long name). So there actually is a reason for the differences - and otherwise they are practically identical!
Checked in, changeset id: 164:88e95f865bb6
Whiteboard: [has patch]
Target Milestone: --- → Thunderbird 3.0b1
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.