Closed
Bug 97943
Opened 21 years ago
Closed 9 years ago
Sent Folder in "root" recreated even if Sent Folder moved
Categories
(MailNews Core :: Movemail, enhancement)
MailNews Core
Movemail
Tracking
(Not tracked)
RESOLVED
FIXED
Thunderbird 24.0
People
(Reporter: bugzilla, Assigned: aceman)
References
Details
Attachments
(1 file, 1 obsolete file)
3.34 KB,
patch
|
jcranmer
:
review+
|
Details | Diff | Splinter Review |
Hi Since I dont use the Sent, Drafts and Templates - Folders very often and to save space I created a general Folder "Stuff" where I moved all those three folders in and also looked that everything is set correctly in the preferences. The Mailer uses those folders correctly, BUT those three folders are re-created every time I restart Mozilla in the root, no matter how often I delete them. What should be different: Mozilla should see, that those folders are moved and that they already exist so that it doesn't have to recreate them in the main folder of this account. I didn't find another bug which was about exact this phenomenon, though ther are a lot of close hits. (Bug 51906 (Recreation of Sent Folder), Bug 95709 (Problems with changing of Sent Folder)). Maybe it's a related problem, otherwise please make a new one out of it: I tried to move all my Messages in my (moved) sent folder to the re-created one to do some testing. There are 1968 Messages in it. I selected all, moved them to the main Sent Folder, but only 744 of them arrived there. Even when I tried to move the others, there remained those 744 and none of the new ones were added...... Matt
Comment 1•21 years ago
|
||
Marking these all WORKSFORME sorry about lack of response but were very overloaded here. Only reopen the bug if you can reproduce with the following steps: 1) Download the latest nightly (or 0.9.6 which should be out RSN) 2) Create a new profile 3) test the bug again If it still occurs go ahead and reopen the bug. Again sorry about no response were quite overloaded here and understaffed.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Comment 3•21 years ago
|
||
WORKS FOR ME Windows 2000 ./nightly/latest-1.0.0/ Build 2002041617 Reporter: This bug is 8 months old. Have you tried with a newer build? Can someone (reporter?) marked this as fixed or works for me?
Hi Still doesn't work for me! I do the following: Add a Folder named "Stuff" to my main mail. Add a Folder named "Sent" to that folder "Stuff". Go to mail preferences, choose where sent mails should be stored => <my account>/Stuff/Sent Kill the Sent Folder in the root of this account. Empty trash (doesn't matter) quit and restart Mozilla. --> The Sent folder is there again! Using 2002041617 on Win2k... Matti
Comment 5•21 years ago
|
||
BUT! does the mail go to <my account>/Stuff/Sent ??? The creation of the default folder isn't a bug in my opinion. Asking that it's creation be supresses is a feature request. Reporter: If the mail is correctly transfered to <my account>/Stuff/Sent, would you care to change SEVERITY to enhancement? I.E. feature request?
Yes, the mail gets delivered into the right folder. Of course this bug isn't CRITICAL and could be seen as a feature request, but I still think this is a BUG which needs to be fixed.. since you HAVE the functionality to change the default folder, this recreation should be avoided too.. I guess this is hardcoded somewhere and not dependent on what's selected in the preferences? I'm not a mozilla-programmer but I dont think that would be THAT a big thing to have the folder-to-be-recreated as a parameter depending on the settings...? Matti
Comment 7•21 years ago
|
||
Matti, still exists on 1.0RC1 ? If not, set the but to "worksforme"
Yes, still the same problem... Aren't you able to reproduce it? Please tell me what I might do to track this one down if you cant reproduce it.. Matti
Using builds 20020520 and earlier. Matti is correct in stating the Sent, Drafts & Template folders are recreated each time you launch the app if your POP and/or Local Folders don't have one even it they are not designated as folders for for copies of Sent messages, Draft messages and Templates. Since this recreation is by design, this bug is a feature request to allow the user to stop the recreation of these folders if they don't exist and are not needed by the user.Changing severity from normal to enhancement and status as New
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 10•20 years ago
|
||
As the reporter of this bug I cannot quite agree with all you said. I dont want to DELETE them permanently or something like that, I want to MOVE them because I rarely use them and I dont want them to be on top of the structure where I usually have tons of own private folders... So in my case I then have those folders TWICE. Once in 'root' and once in my folder where I want them to be (because I can collapse it and it will only use the height of ONE item. So I think this IS a Bug and not only a feature request? Matti
Updated•18 years ago
|
Product: Browser → Seamonkey
Updated•17 years ago
|
Assignee: sspitzer → mail
Updated•14 years ago
|
Assignee: mail → nobody
QA Contact: esther → message-display
![]() |
||
Comment 11•13 years ago
|
||
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
![]() |
||
Comment 12•13 years ago
|
||
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
![]() |
||
Comment 13•13 years ago
|
||
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
![]() |
||
Comment 14•13 years ago
|
||
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
![]() |
||
Comment 15•13 years ago
|
||
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
![]() |
||
Comment 16•13 years ago
|
||
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
![]() |
||
Comment 17•13 years ago
|
||
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
![]() |
||
Comment 18•12 years ago
|
||
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago → 12 years ago
Resolution: --- → EXPIRED
Comment 19•12 years ago
|
||
Still an issue for Movemail, POP/IMAP seems to work.
Status: RESOLVED → REOPENED
Component: MailNews: Message Display → MailNews: General
Ever confirmed: true
QA Contact: message-display → mail
Resolution: EXPIRED → ---
Updated•12 years ago
|
Status: REOPENED → NEW
Component: MailNews: General → Movemail
Product: SeaMonkey → MailNews Core
QA Contact: mail → movemail
![]() |
Assignee | |
Comment 20•9 years ago
|
||
This could do it. The original code even create the folder files directly on disk, so they were picked up only at next TB start. So if they were missing in the current session, they would still not be available if needed. Strange. This is also done in RSS server type. So now using CreateLocalFolder the folders are seen immediately. I am not sure why POP3 behaves differently and does not need this patch. But maybe we could still use this also in other server types. (I wonder why CreateDefaultMailboxes is separate from SetFlagsOnDefaultMailboxes, with this patch we could set the special flags immediately on the created folders... Could be for another bug.)
Assignee: nobody → acelists
Status: NEW → ASSIGNED
Attachment #761819 -
Flags: review?(neil)
Attachment #761819 -
Flags: review?(Pidgeot18)
Comment 21•9 years ago
|
||
(In reply to :aceman from comment #20) > I am not sure why POP3 behaves differently and does not need this patch. But > maybe we could still use this also in other server types. These days, I think the Sent folder is set up with appropriate flags when you first try to use it, and somewhere along the line people removed the CreateDefaultMailboxes for POP. I don't know off the top of my head, but I think the critical stuff (Sent/Trash) are set up when you first try to use them, so there shouldn't be a need to do that for CreateDefaultMailboxes for Movemail either.
![]() |
Assignee | |
Comment 22•9 years ago
|
||
CreateDefaultMailboxes for POP still exists, just does not create the other folders like Drafs/Templates/Sent : http://mxr.mozilla.org/comm-central/source/mailnews/local/src/nsPop3IncomingServer.cpp#443 Do you mean to also strip the function to only do the Inbox+Trash for movemail ?
Flags: needinfo?(Pidgeot18)
Comment 23•9 years ago
|
||
Comment on attachment 761819 [details] [diff] [review] patch I don't think changing CreateLocalFolder is a good idea as you can redirect special folders and end up with multiple special folders in one account.
Attachment #761819 -
Flags: review?(neil) → review-
![]() |
Assignee | |
Comment 24•9 years ago
|
||
(In reply to neil@parkwaycc.co.uk from comment #23) > I don't think changing CreateLocalFolder is a good idea as you can redirect > special folders and end up with multiple special folders in one account. Yes you can have more in one account. And the new CreateLocalFolder will actually see them and not create another ones. Without the patch it created them under root folder without asking. So I do not understand what is worse with the patch.
Comment 25•9 years ago
|
||
(In reply to :aceman from comment #22) > CreateDefaultMailboxes for POP still exists, just does not create the other > folders like Drafs/Templates/Sent : > http://mxr.mozilla.org/comm-central/source/mailnews/local/src/ > nsPop3IncomingServer.cpp#443 > > Do you mean to also strip the function to only do the Inbox+Trash for > movemail ? Yes
Flags: needinfo?(Pidgeot18)
Updated•9 years ago
|
Attachment #761819 -
Flags: review?(Pidgeot18)
Comment 26•9 years ago
|
||
(In reply to Joshua Cranmer [:jcranmer] from comment #25) > (In reply to :aceman from comment #22) > > CreateDefaultMailboxes for POP still exists, just does not create the other > > folders like Drafs/Templates/Sent : > > http://mxr.mozilla.org/comm-central/source/mailnews/local/src/ > > nsPop3IncomingServer.cpp#443 > > > > Do you mean to also strip the function to only do the Inbox+Trash for > > movemail ? > > Yes Correction: you might not even need Trash, but I'd recommend checking first.
![]() |
Assignee | |
Comment 27•9 years ago
|
||
Thanks. I tested that Drafts and Templates are created automatically. Unsent Messages uses the global unsent folder (may be in other account). Trash is needed to be created here as otherwise Delete message throws.
Attachment #761819 -
Attachment is obsolete: true
Attachment #766333 -
Flags: review?(Pidgeot18)
Updated•9 years ago
|
Attachment #766333 -
Flags: review?(Pidgeot18) → review+
Comment 28•9 years ago
|
||
https://hg.mozilla.org/comm-central/rev/00e582fb8c72
Status: ASSIGNED → RESOLVED
Closed: 12 years ago → 9 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 24.0
Comment 29•9 years ago
|
||
(In reply to Joshua Cranmer from comment #21) > (In reply to aceman from comment #20) > > I am not sure why POP3 behaves differently and does not need this patch. But > > maybe we could still use this also in other server types. > > These days, I think the Sent folder is set up with appropriate flags when > you first try to use it, and somewhere along the line people removed the > CreateDefaultMailboxes for POP. I don't know off the top of my head, but I > think the critical stuff (Sent/Trash) are set up when you first try to use > them, so there shouldn't be a need to do that for CreateDefaultMailboxes for > Movemail either. Ah yes, this briefly confused me when I skimmed the patch, but of course the Sent, Drafts and Templates are properties of the identity, not the server, so they don't belong here. (Fortunately for me this got dealt with admirably anyway.)
You need to log in
before you can comment on or make changes to this bug.
Description
•