[Tickets #10447] Re: New trash folder gets created in the shared namespace

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/10447
------------------------------------------------------------------------------
  Ticket             | 10447
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | New trash folder gets created in the shared namespace
  Queue              | IMP
  Version            | 5.0.10
  Type               | Bug
  State              | Unconfirmed
  Priority           | 1. Low
  Milestone          |
  Patch              | 1
  Owners             |
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2011-08-24 06:01) wrote:

> 1) The problem does not exist for "sane" namespaces. And that is  
> something we can easily detect. If there either exists no namespace  
> without prefix and or it exists but is the default personal  
> namespace then the current code is valid and can be used.

I agree.  If the IMAP server is configured with "sane" values, we  
should leverage those values and allow a power user to create  
mailboxes in the non-default namespace.

> 2) For "insane" namespaces the current code is not valid and would  
> need to be amended. The situation - empty prefix for non-personal  
> namespace - can easily be detected and I see two possible options:
>
>   a) disallow creating "Trash", "Drafts", "Sent", and "Spam" in the  
> shared namespace and always assume that the user refers to the  
> personal namespace.

It's not just the special mailboxes, it's *any* mailbox that can be  
created from a prompt that allows definition of the full mailbox name.  
  (Also, better description of issue: these mailboxes are ONLY allowed  
in the default namespace)

Note that this is NOT an issue when creating mailboxes directly when  
using a UI that allows explicit creation of submailboxes (e.g. dynamic  
view, standard view folders.php).  It is only an issue when presented  
an input box that asks for a full mailbox name (e.g. "Create new  
mailbox" options in pref screens; Ingo mailbox creation; create  
mailbox via folders.php when submailbox is not selected)

>  b) allow the admin to set a "full path has to be used" for an IMAP  
> server specified as backend so that users would have to specify  
> "INBOX/Trash" if they want the folder in personal namespace or just  
> "Trash" if they refer to the shared namespace.

An admin option is pointless, since it is the user's understanding of  
what they can do that matters.  Not sure how you would display an  
admin's decision on a config option like this to the user in any sort  
of reasonable, sane manner that would not confuse 99% of the people  
using the program.

> I think it is quite reasonable to just implement (a). The only  
> folder where I could imagine that users might rather wish to create  
> it in the shared namespace might be the "Spam" folder. All others  
> tend to contain private data that is usually not meant to show up in  
> the shared namespace. So disallowing creation of special folders in  
> the shared namespace does not seem much of a drawback in the "insane  
> namespaces" situation. After all the admin might also still have the  
> option to fix the namespaces in case the limitation introduced with  
> option (a) is considered to severe.

This is a limitation of using an "insane" namespace.  Period.   
Probably should be documented somewhere (INSTALL? backends.php?)