567705 - Remove "IMAP server directory:" from UI, by respecting already supported personal namespace response

Status: NEW

(MailNews Core :: Networking: IMAP, defect)

Description

[WADA:World Anti-bad-Duping Agency]

Remove "IMAP server directory:" from UI, by respecting already supported personal namespace response.

I saw Bug 507200 which is for issue when user intentionally sets "IMAP server directory: [Gmail]" for Gmail IMAP account. And, while testing for analysis of the Bug 507200 and Bug 508838, I saw phenomenon of Bug 511331 by intenstional "IMAP server directory: [Gmail]" of Gmail IMAP account. 
As NAMESPACE extention is already supported by Tb and many IMAP servers, and manual namespace setting is already implemented by uncheck of "[ ] Allow server to overide namespaces", I think there is no need to keep current "IMAP server directory:" which can easily produce useless problems by user's intentional bad IMAP server directory setting.

Required changes.
(1) Remove "IMAP server directory:" from UI.
    Keep mail.server.serverX.server_sub_directory in prefs for minimum change.
(2) Add new "[ ? ] Show namespace as root folder of children" to UI.
    Call namespace_as_root=true/false (or use_server_sub_directory=false/true)
(3) If "[x] Allow server to overide namespaces" is checked,
    and if namespace is supported by IMAP server,
    and if personale name space is returned, 
    and if namespace_as_root=false,
    save first personal namespace in mail.server.serverX.server_sub_directory.
    Else if "[ ] Allow server to overide namespaces" is not checked,
    and if personale name space is specified by user,
    and if namespace_as_root=false,
    save first personal namespace in mail.server.serverX.server_sub_directory.
    Else clear mail.server.serverX.server_sub_directory.

There are still next problem as above is minimum change.
(a) User can put arbitary folder in mail.server.serverX.server_sub_directory
    via Config Editor or prefs.js editing.
    => Same as current. Removing "IMAP server directory:" from UI sufficiently
       reduces useless bugs t B.M.O.
(b) It's impossible to extend to other than personal namespace.
    => Bug 557718 or Bug 80858 will resolve this problem.
(c) Mismatch among namespace, server_sub_directory, and localization still
    remains.
    => Nothing is changed from curren around this issue.
       Bug 557718 or Bug 80858 will resolve this problem.
(d) "[ ] Allow server to overide namespaces" is not appropriate because many
    servers can already support namespace extension. Namespace is merely not
    used by all servers. I think UI like next is better for user wants to
    intentionally override namespace response and for user of very old Courier
    who requires namespace but doesn't support namespace command.
      "[ ] Use above namespaces always regardless of server response"

Comment 1

[Ben Bucksch (:BenB)]

I'm not opposed to this, but UW-IMAP users need this. Their mail is often in .mail or Mail/, and the root is just the user's home directory, and the server doesn't support namespaces, IIRC.
And Redhat IIRC still delivers UW-IMAP as standard IMAP server, unfortunately.

Comment 2

[Ben Bucksch (:BenB)]

> I'm not opposed to this, but UW-IMAP users need this.

Too much "this", I meant: I'm not opposed to removing the UI for this setting, but UW-IMAP users need this setting.

Comment 3

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #1)
> Their mail is often in .mail or Mail/, and the root is just the user's home directory,
> and the server doesn't support namespaces, IIRC.

Server Settings/Avanced already has next setting.
  These preferences specify the namespaces on your IMAP server
     Personal name space [          ]
     Public (shared):    [          ]
     Other users:
    [ ? ] Allow server to override these namespaces
If user sets 'Personal name space [ "mail." or "Mail/" ]',
and if user unchecks '[ ] Allow server to override these namespaces',
and if Tb respects 'Personal name space [ "mail." or "Mail/" ]' setting,
and if user unckecks new '[ ] Show namespace as root folder of children',
it's similar to current 'IMAP server directory: mail or mail. or Mail or Mail/' for such UW-IMAP server who requires namespace but doesn't support namespace command.
Ben Bucksch, is it wrong?

Comment 4

[Ben Bucksch (:BenB)]

I don't know, I don't have an UW-IMAP anymore, but I vaguely remember that this did not work.

Comment 5

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #4)
> but I vaguely remember that this did not work.

What do you mean by "this"? What didn't work?
You set 'Personal name space [ "mail." or "Mail/" ]' but folder creation request of AAA under IMAP account didn't crete mail.AAA nor Mail/AAA?
Or You set 'Personal name space [ "mail." or "Mail/" ]' but folder of mail.XYZ or Mail/XYZ was shown as mail.XYZ or Mail/XYZ at folder pane instead of root level XXX?
If latter, it's not surprizing because Tb doesn't respect namespace response nor 'Personal name space [ "mail." or "Mail/" ]' setting by user upon folder display at folder pane. So your Bug 557718 and/or Bug 80858 was opened, wasn't it?

Comment 6

[Ben Bucksch (:BenB)]

> What do you mean by "this"? What didn't work?

To set ".mail/" or "Mail/" in:
     Personal name space [ .mail/    ]
     Public (shared):    [ .mail/    ]
as you suggest. But as I said: IIRC.

Comment 7

[Ben Bucksch (:BenB)]

Bug 557718 is about where to display the subfolders of INBOX.

For UW-IMAP, if you try to display or just list ~, you get the whole home directory with all folders, files and dotfiles.

Comment 8

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #7)
> For UW-IMAP, if you try to display or just list ~, you get the whole home
> directory with all folders, files and dotfiles.

If "Personal name space [ .mail/ ]" is specified by user, it's same as "server returned .mail/ to NAMESPACE command". Tb probably issues LIST ".mail/%/%" because personal namespace=".mail/", and Tb issues LIST ".mail/ABC/%/%" when folder of .mail/ABC is opened. Response to such IMAP command is up to IMAP server. The UW-IMAP merely returned dirctories/files under .mail to such LIST command. 
This bug is request for auto-hide of ".mail" in your UW-IMAP case at folder pane, without "IMAP server dirctory:".  

> Bug 557718 is about where to display the subfolders of INBOX.

INBOX, only folder which any IMAP server MUST provide and support, and NAMESPACE are independent. NAMESPACE itself is irrelevant to special folder of INBOX. Some server want IMAP client to create any folder under INBOX, so such server merely returns "INBOX. or INBOX/" to NAMESPACE command, and some server doesn't support NAMESPACE command.
Multiple personal namespaces is supported and multiple shared namespaces and multiple other user's namespaces are also supported by NAMESPACE extension. As your request by Bug 557718 is "proper usage of NAMESPACE response", I expect auto-hide of multiple namespaces will be implemented in your Bug 557718. 
Ehancement by this bug can auto-hide first personal namespace only.

Comment 9

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #4)
> I don't know, I don't have an UW-IMAP anymore, but I vaguely remember that this
> did not work.

"didn't work" around 2000-03-01 when you opened bug 29782? Or around 2007-05-25 when you added last comment to bug 29782?

Comment 10

[WADA:World Anti-bad-Duping Agency]

Following is a part of bug 517054 comment #0 opened on 2009-09-16.
> The UW-Imap Server supports public (#public) and shared (#shared) folders in
the imap namespace.
Ben Bucksch, your referring to very old UW-IMAP in this bug is merely an example of server of "server requests namespace but server doesn't support namespace command" for which user has to manually set namespace setting at "Advanced" of Server Settings?

Comment 11

[WADA:World Anti-bad-Duping Agency]

Ben Bucksch, "but UW-IMAP users need this" in your comment #1 is applicable to currently living Tb or Seamonkey users?