Need reduced UI for adding/using IMAP folders for non-sending shared accounts.

RESOLVED EXPIRED

Status

--
enhancement
RESOLVED EXPIRED
15 years ago
13 years ago

People

(Reporter: llaughridge, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
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
12345@example.dom  23456@example.dom  and 45678@example.dom  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 23456@example.dom and they click 'Reply' or
'Compose', they default to sending as '23456@example.dom' 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)
(Reporter)

Comment 2

15 years ago
(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.
Product: Browser → Seamonkey

Updated

14 years ago
Assignee: sspitzer → mail
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.