Changes have been made in Git for this ticket:

Bug #10447: changelog

  1 files changed, 1 insertions(+), 0 deletions(-)
http://git.horde.org/horde-git/-/commit/49de111b857ef1aab6ef66eedf85a72370390431

Works fine. Thanks a lot!

Changes have been made in Git for this ticket:

Bug #10447: Fix for mailbox creation in mailbox standard view

  1 files changed, 2 insertions(+), 1 deletions(-)
http://git.horde.org/horde-git/-/commit/f812786ff486402fdf839d7f3228119051056edb

Try this fix attempt.

Changes have been made in Git for this ticket:

Bug #10447: Fix namespace auto-detection for non-sane namespace configs

  4 files changed, 37 insertions(+), 8 deletions(-)
http://git.horde.org/horde-git/-/commit/406106956a76f97091dbb00f06c1b8249e4d790a

So as I see it, there are three locations that need to be fixed.

* namespace_append calls in imp/lib/Prefs/Ui.php
* Calls to IMP_Mailbox::copy() that use the 'create' parameter
* The IMP createFolder API call.

For the API call, there needs to be a way of distinguishing between 
creation of a full mailbox name and creation of a mailbox within the 
default namespace (since a calling application will most likely not 
want to mess its hands with namespace annoyingness).

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.
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)
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.

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

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 :)

*Sigh*... this issue again.  Unfortunately your proposed solution is 
wrong because it breaks servers that use sane values for namespaces.

Obviously, namespaces can be whatever they want to be per the RFC 
definition.  But in practice, using anything other than the empty 
namespace for personal mailboxes is a terrible, terrible idea.  See, 
e.g., 
http://mailman2.u.washington.edu/pipermail/imap-protocol/2007-August/000652.html

The issue comes with user input.  If I want to specifically*create a 
mailbox in a shared mailbox, I should be able to pass in the full 
mailbox name (including namespace).  Everything else should be 
interpreted as a mailbox being created in the default namespace.

The problem with using something other than the empty namespace as the 
personal namespace (or, more accurately, using the empty namespace for 
something OTHER than the default personal namespace) is that it is no 
longer possible to correctly auto-determine namespaces from user 
input.  E.g. Trash - you are making an assumption that they want to 
create INBOX.Trash.  However, an equally valid assumption is that they 
want to create a mailbox in a shared mailbox named Trash.  Therein 
lies the problem.

IIRC, the "solution" we previously came up with is essentially that we 
ALWAYS assume that user input is in the personal namespace only.  In 
other words, we prevent creation of mailboxes outside of the personal 
namespace.  However, this is a terrible compromise IMHO (although it 
might be necessary given the "broken" IMAP servers, e.g. Courier, 
Cyrus, that use terrible defaults for namespaces).

Similar fix might then be applied to the _updateSentmail($ui) method.

When creating a new "Trash" folder via the preferences IMP fails with 
"Permission denied" as the code tries to create the folder in the 
shared namespace (given that the user does not have the permission to 
create folders there).

On a default Kolab server the users have the personal namespace with 
prefix "INBOX", the other namespace with prefix "user", and the shared 
namespace with no prefix.

When trying to create a new "Trash" folder the code automatically 
selects the shared namespace without prefix as a default. As far as I 
can see there is no method to change this behaviour via a configuration.

My assumption would be that a "Trash" folder would always be created 
in the personal namespace. In fact the method IMP_Mailbox::prefFrom() 
seems to indicate that this is the intended way how it should work. So 
maybe this would be an appropriate fix:


diff --git a/imp/lib/Prefs/Ui.php b/imp/lib/Prefs/Ui.php
index bd69b5c..536bf41 100644
--- a/imp/lib/Prefs/Ui.php
+++ b/imp/lib/Prefs/Ui.php
@@ -1831,7 +1831,7 @@ class IMP_Prefs_Ui
              $folder = IMP_Mailbox::get(substr($folder, 
strlen(self::PREF_SPECIALUSE)));
          } elseif (!empty($new)) {
              $new = Horde_String::convertCharset($new, 'UTF-8', 'UTF7-IMAP');
-            $folder = IMP_Mailbox::get($new)->namespace_append;
+            $folder = IMP_Mailbox::get(IMP_Mailbox::prefFrom($new));
              if (!$folder->create(array('special_use' => array($type)))) {
                  $folder = null;
              }