[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         | Gunnar Wrobel <wrobel at pardus.de>
  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             |
------------------------------------------------------------------------------


Gunnar Wrobel <wrobel at pardus.de> (2011-08-23 19:04) wrote:

I admit I didn't see the problem you described before and I agree it  
exists. A user saying "I want 'Trash' to be created" could mean  
"INBOX/Trash" or just "Trash" in the shared namespace if the prefix of  
the default personal namespace is "INBOX/" and "" for the default  
shared namespace.

BUT...

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.

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.

  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.

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.

I would only implement (b) in case there is some protest about this  
being something that really needs to be configurable. But based on the  
reasoning above I really don't expect that.

Do you agree? If so - is this something I should start coding a patch  
for? Because I really need to get that fixed :)