I believe the spec says to default those prefs to the imap server. I haven't implemented that yet. It's a little trickier, and I wanted to fix the pop, news, and local folder case first. right now, for imap, I default to folders on "Local Folders". I think my main concern right now is this: for a new imap server, to find the Sent folder, we may have to log in and discover it. there is no way around that, right? if so, this would mean having a dialog box pop up while using the account manager / prefs.

Since then, may questions have been raised about this. In addition, there has been a lot of questions about what folders are created by default and which folders are created as needed. And exceptions keep arising. I think it would be a good idea to spend the next issues meeting reviewing this behavior and agreeing on the best solution.

new account issue, not migration issue. marking m14.

marking p2

Would like to have this fixed for B1. I think we decided to try an implementation which would allow us to specify a folder in the prefs UI, even though we haven't discovered the folder yet.

moving to m15.

moving to m16.

Hey Phil, beta2?

Mass moving M16 to M17 - look for nsbeta2 before anything else.

Yes, I think we should try to fix this, since having the special folders for an IMAP account be on the local disk makes IMAP much less useful. Maybe [6/1]. Alec or Seth, what happened to the folder picker which could contain folders which hadn't been discovered yet?

Putting on [nsbeta2+][6/01] radar. This work must be done by 06/01 or we may pull this for PR2.

*** Bug 41257 has been marked as a duplicate of this bug. ***

not going to fix this for nsbeta2, I doubt we'll get to it for 6.0 marking m30 there is a work around. You can use the account manager to change the copies and folders prefs. given that "mailbox://nobody@Local Folders/Sent" always exist, we avoid a lot of problems by defaulting to it.

Adding myself to cc: list

Summary of the Issue's meeting on this topic can be found here: http://gooey/client/5.0/specs/mail/messenger/MeetingNotes/Notes_12_16_99.html

moving to future milestone.

In most of the Multilple Account Usability tests that I've seen, user's expected to see messages in a folder associated with the selected account and not Local Folders.

Seconding nbaca's comment. In the multiple accounts usability test we have 2 tasks that address this. One is to have the user compose a message, save the message to be completed later (Draft), and then in a later task, ask them to find the Draft and complete it. In the second task, we ask them to find a copy of a message they just send (in previous task) and forward it to someone else. For both tasks above (Send and Drafts folder), every subject so far in usability testing (5 so far, more to come) has expected to find the message they are looking for in the Draft, or Send Folder respectively, associated with the account from which they sent the message.

moving to M18 and nominating for nsbeta3.

*** Bug 45539 has been marked as a duplicate of this bug. ***

Mail Triage is marking [nsbeta3-]

EVERY single person during usability testing had a problem with this. EVERYONE expected mail to go to the Send and/or Draft folder associated with the account. People were very unhappy about Send and Drafts defaulting to Local Folders. Most users don't even understand what Local Folder are. Remove nsbeta3- so this can be re-evaluated.

Sounds like a strong case. The only issue is how confident we are we can fix this.

Preliminary usability results: These are the facts. 7 users out of 7 tested checked the account from which it was sent first. They checked other accounts second and then finally they went to local folders. Only by process of elimination did they find this and a few assumed that it did not work and did the send/save operation again. This Failed the usability test!

the problem is - Fixing this is hard - Seth is not here, and he's the expert on this stuff..

That's what I thought. If we don't have an ETA or a fix in hand, or at the very least "the guy that knows how to fix this," I don't know if we have any other choice but to ship without it getting fixed. A tough one, yes, but what are the alternatives?

How hard is this to do? If I remember correctly this had to do with faking out the folders that a Sent folder existed even though it didn't realy exist on the server. How bad is it to create a Sent folder by default? I know that we've worked hard to not have to do this. That's one way around this bug. Anyway, just looking for opinions if there's any easy, acceptable way to fix this.

+ per mail triage, P2.

Adding ue1 because i felt like it? akin to dveditz@netscape.com's nsbeta2/nsbeta3 keyword mass spams.

Personally, I don't like clients that deliberately add folders to my server. But this is common practice, and IMO the much lesser evil than defaulting to local folders, especially considering new users. If the user is unhappy with the default choice, he can still delete the folder and specify another one. (But see bug 11689).

All we need to do is default the preference to the on-server folder. We don't have to create it - we will lazily create it or discover it the first time the user does something to populate the folder (send a message, save a draft or template, etc) because I fixed the bug where we weren't doing that.

I'll lok at doing this - I don't know the code, but Jeff, Alec, and Seth aren't around.

I'm back! The code should be in AccountWizard.js or accountUtils.js, I can't remember. The one concern we had was how to represent this in the UI for the copies & folders in the account manager.. but I think that's secondary at this point

Some of the code is in accountWizard.js, but it's a bit trickier than I first thought. I need to change nsImapService::GetDefaultCopiesAndFoldersPrefsToServer to say that by default, imap servers should have those folders online. But, AOL imap servers shouldn't, because we can't create folders. Unfortunately, GetDefaultCopiesAndFoldersPrefsToServer is a method on the service, and doesn't know which particular server is involved. So I would need to change it to pass in the server, and have the server check if it's an AOL server (or more generally, a server which can't create folders, but that's pretty much limited to AOL servers. There is also the case of Cyrus servers which want all folders to be sub-folders of the inbox, which means we can't just assume that "Drafts" is a top-level folder, for instance. As much as it pains me, this is getting to be complicated, so I'm moving to p3, and I'm going to work on other stuff first.

Well, I think IMAP is the hardest problem to solve, with the least usage. For now we could just solve this for POP...(as I recall from the usability studies, POP does in fact have the identical problem)

This is only an IMAP problem. POP accounts already have folders (Sent, Draft and Templates) pointing to the account and not Local Folders.

To add to that, AOL Mail and WebMail use IMAP, so the "IMAP won't be used as much as POP" theory may not be accurate. In addition, the relative (low) savviness of AOL and WebMail users may prevent them from figuring out the workaround. That being said, I recommend making this a P1.

I'm afraid this is just one of those issues that we punted on for way too long, and now it's too late.

per mail triage, mark P1. David, I just saw your note that this bug was too hard to address at this time. I'll email mailtriage to see if we can reconsider the + on this.

after consulting with david and mailtraige, we will minus this.

Sorry for the extra mail. Removing mail4 keyword.

Adding mail3 to keywords because user's expect to see their messages saved to the account's draft/templates or sent folder, not Local Folders.

marking nsbeta1+ and moving to mozilla0.9

moving to mozilla0.8 milestone.

reassigning to racham for ui portion of this.

moving to mozilla0.9

moving to mozilla0.9.1

*** Bug 77204 has been marked as a duplicate of this bug. ***

*** Bug 77184 has been marked as a duplicate of this bug. ***

moving to 0.9.2.

changing milestone to match my last comment

Bhuvan, could you attach a patch for your UI changes so that I can try them? I don't know what else to do.

OK, here's the problem: In mailnews/compose/src/nsMsgCopy.cpp, nsMsgCopy::GetSentFolder() calls LocateMessageFolder for the fcc folder by pref. This fails, and we never try to create the imap folder online so my imap code never gets called. nsresult ret = LocateMessageFolder(userIdentity, nsIMsgSend::nsMsgDeliverNow, mSavePref, folder); Bhuvan, let me know if you need more help. I can try to come up with a fix for the compose code, but it might be better if you drove it so you can check all this in at once. My suggestion would be to look at this code in LocateMessageFolder: rv = folderResource->GetServer(getter_AddRefs(server)); if (NS_FAILED(rv)) return rv; if (!server) return NS_ERROR_FAILURE; this is causing the problem - because the uri is for a folder that doesn't exist, the uri doesn't have a server, and we pretend to fail to not find the folder.

OK, I'm working on fixing the compose part of this problem. I'll try to attach a patch in a day or so.

I will be attaching couple of screenshots and also a list of patches to supporting that UI. Details : 1. Spec provided by Jennifer for UI 2. ScreenShot for a new IMAP account (radio buttons are selected, but folders are yet to be created. David is working on wrapping up those issues). 3. ScreenShot for a new POP account (radio buttons are selected and folders exists in this case, as for POP accounts we always created special folders locally). 4. ScreenShot for a new NEWS account (default to local folders here) 5. ScreenShot for an existing account (This is how the UI will be displayed for existing accounts i.e., select radio button to display the current settings) 6. mailnews patch, ver 1 7. themes patch, ver 1

Racham, the screenshots look great! However, do you think you could make the radiobuttons have a little less vertical space in between them?

This fix makes it so will try to create an imap folder if it doesn't exist, basically by removing a bunch of error checking in the compose code that was preventing the imap code from getting called. Bhuvan, can you shepard this fix through the test+review+checkin process in with your fixes since I'm going to be on vacation? Please let me know if you have any questions. Thanks!

Thanks David. I will take care of the rest. Will post test results here soon. bhuvan

David, We are almost there with a single exception (which is not a major case anyway). Here are the scenarios : 1. New profile : a. Create a new IMAP account b. No sent, draft or template folders c. Bring up compose window (New Msg) d. compose a sample message e. Send the message f. Sent folder is created and message is copied into the folder g. Drafts & Templates folders are also created on demand h. All sucessful results. 2. Existing profile : a. This could be any profile with Sent (& other special folders already existing) b. Delete Sent folder c. Empty Trash (to remove any traces) d. Now bring up the compose window e. Compose a message and click on Send f. 'mailbox does not exist error dialog' shows up g. On subsequent launch with same profile, message send operation succeeds in creation of sent folder and send operation itself (+copying the sent message into Sent folder). So, the only case that fails now is the manual delete of Sent (or other Special folders) and trying to trigger operation which use those folders in the same session. Attaching the IMAP log for david to take a look. I will step through the code to find out more. bhuvan

fyi, applied david's patch before running the test scenarios.

thanks, Bhuvan, I did encounter the one problem case you describe. I don't think you should be allowed to delete the sent folder, actually, so I think it would be better to prevent that instead of fixing the code to work (it might be a bit tricky, since most of the tests we use to detect if a folder exists are foiled if you delete the folder in the same session).

David, I agree with you. Let us prevent users from deleting special folders at the front-end layer itself. Scott, Jennifer, Are you OK with this ? If anyone else has any other ideas, please do update the bug. bhuvan

If a user has an IMAP account, is first using the "Sent" folder on the IMAP server as their default location for sent messages, and then changes their default for sent messages to the Local "Sent" folder, can they now delete the "Sent" folder on the IMAP server since it is no longer special?

Jen, yes, they can delete the online sent folder then. And it is true that if the user does all of this in the same session, and then changes the sent folder to be the online sent folder again, they will run into the remaining bug. But not if they shutdown in between, which reduces the problem to a vanishingly small one.

I think it's fine to prevent the deletion of the Sent folder.

The latest patch (id:38680) prevents deletion of special folders 'Sent', 'Drafts' & 'Templates'. In the attached screen shot followed (id:38682), the error message says Deletion of special folder Sent is not allowed for imap accounts. Note : I have already capitalized word imap to say Deletion of special folder Sent is not allowed for IMAP accounts. Seth is looking at the patch right now. Adding mScott to the cc list for super review. Will send mail reminder also. bhuvan

+specialFolderDeletionErrTitle=Special Folder deletion "deletion" should probably be capped, right?

this looks likea good start. some minor points so far: 1) spelling mistake +// defaukt picker mode for copies and folders +gDefaulltSpecialFolderPickreMode = "0"; defaukt -> default gDefaulltSpecialFolderPickreMode -> gDefaultSpecialFolderPickerMode 2) spelling mistake + var gDefaultPikcerMode = "1"; gDefaultPikcerMode -> gDefaultPickerMode 3) too many args + SetGlobalRadioElemChoices() + function SetGlobalRadioElemChoices(fccPikcerMode, draftsPickerMode,tmplPickerMode) you need to remove those unused arguments. 4) spelling mistake "Default pikcer mode" -> "Default picker mode" 5) special casing based on type, instead of attributes of protocol info. + if (msgFolder.server.type == "imap") this one is because we want make it so we use the imap://user@host/Sent, but it doesn't exist yet. (you should add a comment about that to AccountWizard.js) you should add an new attribute to nsIMsgProtocolInfo for this. + if (type == "nntp") { this one is because the default folders live on the local folders account. because you've fixed the imap case with your patch, you can do this instead: + if (!protocolInfo.defaultCopiesAndFoldersPrefsToServer) { 6) +<!ENTITY sentFolderOn.label "&quot;Sent&quot; Folder on:"> you need a localization note. "Sent" is always "Sent", see bug #64199 (same for the other new strings you added) one day this won't be the case. see #57440. but until then, you have to add a localization note. on a related note, reading #64199, someone decided that "Templates" (templatesFolderName) could be localized. this is not the case anymore, and you should update messenger.properties to reflect this. 7) command handler within a <template> oncommand="PickedMsgFolder(event.target,'msgStationeryAccountPicker')" your oncommand handler is inside the <template>. for performance reasons, your on command handler should be moved out to the <menu>. I think we've got a bug about fixing all the pickers. so, if you'd rather land and fix all the pickers at once later, that's ok. my only other concerns are: 1) do we do the right thing in the account wizard when switching between servers? do we only make changes on saving? 2) for your new pickers, we only show servers, right?

1) do we do the right thing in the account wizard when switching between servers? do we only make changes on saving? We do the right thing. Changes are saved on changing the panel OR on clicking the OK button. 2) for your new pickers, we only show servers, right? Yes. We just list the servers for new pickers. thanks for the review. Good points. I generalized the attributes whereever possbile. Please revisit the patch. Meanwhile, I will attach some test cases and results in the bug report. bhuvan

Seth, Please ignore Index: base/search/resources/content/SearchDialog.xul changes in the patch 38814. It's not related to this bug. In patch 38815, I fixed the typo in line + var protocolinfo = Components.classes["@mozilla.org/messenger/protocol/info;1?type=" + server.type].getService(Components.interfaces.nsIMsgProtocolInfo); to have var name as protocolInfo. Adding this just to be precise on the change. bhuvan

two comments: 1) spelling mistake: in your latest patches, search and replace "pikcer" -> "picker" 2) your XUL template that you use to list all the servers for new pickers looks wrong. It is supposed to be all top level account except for news account, right? you should have two rule blocks: nc:IsServer="true" nc:ServerType="nntp" and nc:IsServer="true" using nc:CanFileMessages="false" iscontainer="true" isempty="false" is incorrect. There are "no select" imap folders that will show up in your rules.

one other spelling mistake: "gloabl" -> "global"

In the latest patch (ID:39028), * Clean up (removal of dump statements, spelling corrections, fixing indentation & adding more comments) * Changed server picker templates in msgFolderPickerOverlay.xul to 'IsServer' based rule blocks (as suggeted by Seth). Thanks Seth. It works fine. bhuvan

you shouldn't need + SpecialFolder="rdf:http://home.netscape.com/NC-rdf#SpecialFolder" + BiffState="rdf:http://home.netscape.com/NC-rdf#BiffState" in your templates. there won't be any special folders, and we don't care about biff state in the picker. that will just increase mem usuage and slow us down. once you fix that, r/sr=sspitzer

sr=sspitzer

Navin is currently reviewing ths code.

bhuvan has explained his fix to me; r=naving

a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)

Marking Fixed.

This seems impact AOL account....see bugscape 6652 http://bugscape.mcom.com/show_bug.cgi?id=6652

Time for another edition of `that pref panel's way too large for the window'! The fun is in bug 86992.

Build 2001-06-21-04: WinMe Reopening due to problem 2a* below. All other scenarios were successful. Will check the Mac next. 1. Created a new profile, configured for an IMAP account, Copies and Folders point to the IMAP account as expected. Successfully Saved as Draft, Saved as Template and message was sent to the Sent folder. 2. Used a previous build and deleted the IMAP account's Draft, Template and Sent folder. Using the 6/21 build I created a new profile, configured for an IMAP account and the folders were not present as expected. Created a new message and: a. Save as Draft * created a Draft folder but the message was not saved. After an Exit/Restart then the message appeared in the Draft folder. - created a Draft folder and the first message was not saved, although a second and third message was saved. b. Save as Templates - Created a Template folder - First, second and third message was saved to the Template folder C. Sent - Messages sent were saved to the Sent folder

I dulicated the problem using 2 different accounts (qatest33 on nsmail-1 and qatest22 on nsmail-2).

moving to 0.9.3

Build 2001-06-22-04: Mac 9.04 Interesting that on the Mac all the scenarios worked. Even 2a* since the message appears in the Draft folder immediately. I'll try a newer windows build.

If I can reproduce the case you are having problems with, I will post IMAP log. mScott or david can probably let us know why that specific case fails. Looks like some asynchronous actions are taking place. I thought we started copying only when the folder creation is confirmed.

Build 2001-06-25-03: WinMe It appears to be working now on windows. I'll check linux next.

Build 2001-06-25-06: Linux RH 6.2, also works. Marking Resolved/Fixed.

Verified Fixed.

Sorry for coming up so late, but I didnÄt think that you would change the Account Manager UI in this way. Why to we have the default folder names hardcoded in the UI with a radiobox? I think, this is completely unnecessary and it has several disadvantages. Created bug 91551 for it.

*** Bug 52851 has been marked as a duplicate of this bug. ***