Yes, that finally fixed it. Many thanks!

Does this fix it?

http://cvs.horde.org/diff.php/imp/folders.php?r1=2.345&r2=2.346&ty=u

Exactly. And IIRC we agreed earlier in the "namespace ticket" or 
somewhere else, that this is a viable solution, because regular users 
shouldn't be able to create top-level mailboxes in the shared 
namespace anyway.

Sound like i didn't explain myself well enough.



Imagine I am using the brand new foo IMAP server.  I configure it as follows:

personal namespace = 'INBOX.'

shared namespace = ''



I have 1 mailbox in the INBOX namespace named 'foo1'.  I have 1 
mailbox in the shared namespace named 'foo2'.



Therefore, my folder hierarchy looks like:



INBOX

foo1

foo2



Q: how do i create a new mailbox in the empty namespace?  A: I can't.   
Trying to create a folder without checking a box will create the 
folder under 'INBOX.'.



As mentioned below, we could go back to the old way of displaying 
items which would result in a display like the following:

INBOX

   foo1

foo2



But this has the horrible effect of causing all new folders to be 
created when no mailboxes are checked in the shared namespace, not the 
personal namespace (which is probably not what either the user nor the 
admin wants).



As stated previously, I think the solution in this case is requiring a 
confirmation screen in the case where there is a non-default namespace 
that is the empty string.

FWIW, I am also seeing this problem on a Courier installation.

..at least on our cyrus configuration this works fine.

The same problems come up when trying to create folders within Ingo

No, because we already agreed that users can only create mailboxes 
inside existing shared mailboxes. And shared mailboxes are the empty 
ones on Cyrus, and you can create new folders inside of them by 
ticking the corresponding shared parent mailbox.

So this is happening because cyrus must have a private or public 
namespace defined that is empty (i.e. '').  Fixing this by always 
using the default namespace won't work because then it is impossible 
to create folders in an empty namespace.



A workaround would be to go back to the old way of displaying folders 
(i.e. if the default namespace is INBOX, display all folders under 
INBOX).  But as discussed previously, this is bad because 1) it *is* 
more confusing to users (see Bug 2422 for discussion) 2) if create is 
selected without clicking a folder, the folder is created in the blank 
namespace *not* the personal namespace (which is almost certainly what 
the user and/or admin wants) and 3) this will require the user to 
*always* insert the personal namespace information ('INBOX.foo' for 
example) when renaming, which most certainly is not what we should be 
asking users to do.



Quite honestly, this appears to be an issue with the web interface vs. 
a OS-specific GUI interface.  On an OS-specific GUI interface, all 
sorts of boxes and drop down menus can be provided to explicitly 
ascertain what the user wants, or a user can right-click on the 
mailbox where he wants to add a folder, etc..  In our (current) web 
interface, it is difficult to accomplish this without adding a bunch 
of javascript or something similar (bloat/possibly not cross-browser 
compliant).



One solution - we add an intermediate confirmation page in the 
instances where the user's input is unclear - this would only occur on 
systems where there is a blank non-personal namespace and only when 
renaming folders or creating folders without selecting a folder on the 
folders page.



Comments/suggestions would be great.

I can not duplicate this with either creating or renaming a folder.

My tests:

my base namespace is 'INBOX'

I am going to the folders page and immediately selecting 'create a 
folder'.  I enter the folder name 'foo', and 'foo' is created in the 
base namespace (i.e. 'INBOX.foo').  When I check 'foo' and select 
'rename', I set the rename value to 'bar' and 'INBOX.foo' is 
successfully renamed as 'INBOX.bar'.

No, nothing changed, it still behaves the same.

This was a typo in the code - the code was there to convert the 
namespace, the renaming was just using the wrong variable.  Fixed.

Uh, it even looks like the folder that I tried to rename got lost 
during this operation. I have no idea how that happened. Hm, looking 
further, the folder is still there, just not displayed by IMP anymore, 
even after logging in again, weird.

If I want to create a new folder, or try to rename one in the folder 
view, I get "permission denied". I guess IMP is not prefixing the new 
folder with the personal namespace, thus not creating a subfolder of 
INBOX, but one next to INBOX. This is using Cyrus as usual.