6.0.0-git
2019-05-27

[#2874] Not prefixing with personal namespace
Summary Not prefixing with personal namespace
Queue IMP
Queue Version HEAD
Type Bug
State Resolved
Priority 3. High
Owners jan (at) horde (dot) org, slusarz (at) horde (dot) org
Requester jan (at) horde (dot) org
Created 2005-10-27 (4960 days ago)
Due
Updated 2005-12-08 (4918 days ago)
Assigned 2005-12-08 (4918 days ago)
Resolved 2005-12-08 (4918 days ago)
Milestone 4.1.0
Patch No

History
2005-12-08 08:43:46 Jan Schneider Comment #14
State ⇒ Resolved
Reply to this comment
Yes, that finally fixed it. Many thanks!
2005-12-08 05:47:08 Michael Slusarz Comment #13
State ⇒ Feedback
Reply to this comment
2005-11-13 23:09:58 Jan Schneider Comment #12 Reply to this comment
Q: how do i create a new mailbox in the empty namespace?  A: I can't.
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.
2005-11-13 20:30:27 Michael Slusarz Comment #11 Reply to this comment

[Show Quoted Text - 9 lines]
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.
2005-11-09 20:53:22 mrubinsk (at) horde (dot) org Comment #10 Reply to this comment
FWIW, I am also seeing this problem on a Courier installation.
2005-11-08 13:06:18 adrieder (at) sbox (dot) tugraz (dot) at Comment #9 Reply to this comment

[Show Quoted Text - 9 lines]
..at least on our cyrus configuration this works fine.
2005-11-08 13:03:33 adrieder (at) sbox (dot) tugraz (dot) at Comment #8 Reply to this comment
The same problems come up when trying to create folders within Ingo
2005-11-08 12:39:54 Jan Schneider Comment #7 Reply to this comment
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.
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.
2005-11-08 01:46:05 Michael Slusarz Priority ⇒ 3. High
 
2005-11-08 01:45:43 Michael Slusarz Comment #6 Reply to this comment
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.
2005-11-03 11:34:19 Jan Schneider Assigned to Jan Schneider
State ⇒ Assigned
 
2005-11-03 05:44:36 Michael Slusarz Comment #5
State ⇒ Feedback
Reply to this comment
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'.
2005-11-02 22:51:36 Jan Schneider Comment #4
State ⇒ Assigned
Reply to this comment
No, nothing changed, it still behaves the same.
2005-11-01 22:06:35 Michael Slusarz Comment #3
State ⇒ Resolved
Reply to this comment
This was a typo in the code - the code was there to convert the 
namespace, the renaming was just using the wrong variable.  Fixed.
2005-10-27 07:40:53 Jan Schneider Comment #2 Reply to this comment
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.
2005-10-27 07:37:19 Jan Schneider Comment #1
Type ⇒ Bug
State ⇒ Assigned
Priority ⇒ 2. Medium
Summary ⇒ Not prefixing with personal namespace
Queue ⇒ IMP
Assigned to Michael Slusarz
Reply to this comment
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.

Saved Queries