User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 We use IMAP accounts for shared storage of project-related email (approximating the MS Outlook 'shared folders' concept, pardon the analogy). For example, someone who is working on these three projects may be subscribed to firstname.lastname@example.org email@example.com and firstname.lastname@example.org in addition to their normal JoeUser@example.dom account. Given that some people are subscribed to as many as 20 different projects, this presents a serious problem with usability. The first problem is getting the person subscribed to the account. Even being provided with a multi-page annotated-screenshot HowTo, they balk at going through all of the steps for the account wizard every time. Furthermore, the account adding UI provides too many opportunities to make mistake -- sometimes they pick 'POP' instead of 'IMAP' and suck a bunch of mail from the server to a local account, for example. The worst problem is that for (n) shared accounts that they are subscribed to for filing and searching, they now have (n+1) choices for the account to send from in the compose window. If they are browsing something filed under email@example.com and they click 'Reply' or 'Compose', they default to sending as 'firstname.lastname@example.org' rather than as JoeUser@example.dom. This is a big, big, problem for us. What I would like is a reduced UI for subscribing to IMAP folders in addition to, not replacing, the normal 'Add Account' system. This UI would be invoked from File --> Add Shared Folder... and would ONLY prompt for the account name & password in a one-step dialogue. Clicking OK would make the IMAP folder appear in the folder list. Under Mail & Newsgroup Account Settings there would be no sending options for that account, and in the Compose window there would be no option to send 'as' that account. Please? Reproducible: Always Steps to Reproduce: 1. In MailNews, File --> New --> Account and follow the wizard 2. 3. Actual Results: Prompted for unnecessary (for me) information about outgoing servers. Created another IMAP account/identity that the user can send from besides their usual one (undesired, for me). Expected Results: Simple UI to subscribe to a shared IMAP account. Should ONLY prompt for account name, password, and nothing else. Since this account stores messages filed by multiple users within a workgroup, it should NOT provide any UI for sending.
What's wrong with subscribing to folders? (just like outlooks shared folders in fact)
(In reply to comment #1) > What's wrong with subscribing to folders? (just like outlooks shared folders in > fact) If you're talking about File --> Subscribe... in MailNews, that is for subscribing to folders *within* a single IMAP account. What I'm talking about is adding non-sending access to separate IMAP accounts for each shared topic. With the Subscribe... feature, once someone has access to that one IMAP account there is no ability to restrict who gets into what. With separate IMAP accounts, if you don't have the password you can't map the account to begin with, so we can be more granular with access controls. Each shared account for a project will have multiple folders underneath it for various phases/topics, which would also be too cumbersome in a single shared account with up to 100 people storing hundreds of projects worth of info in it.
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.