6.0.0-git
2019-05-19

[#8468] Renaming public folder is wrong
Summary Renaming public folder is wrong
Queue IMP
Queue Version 4.3.4
Type Bug
State Resolved
Priority 2. Medium
Owners slusarz (at) horde (dot) org
Requester frank.richter (at) hrz (dot) tu-chemnitz (dot) de
Created 2009-07-31 (3579 days ago)
Due
Updated 2010-01-13 (3413 days ago)
Assigned 2009-08-05 (3574 days ago)
Resolved 2009-08-06 (3573 days ago)
Milestone 4.3.5
Patch No

History
2010-01-13 00:10:01 CVS Commit Comment #18 Reply to this comment
Changes have been made in Git for this ticket:

Bug #8468: Doing too much magic on rename folder name - we have to 
trust the user at some point.

http://git.horde.org/diff.php/imp/folders.php?rt=horde-git&r1=df8c626194789a61214771c8b5ac07fa870bdc8b&r2=8b659fe604f4a3a6af9ea1509029198bdaafa4e3
2010-01-13 00:09:59 CVS Commit Comment #17 Reply to this comment
Changes have been made in Git for this ticket:

Bug #8468: When appending namespaces, search for empty namespace.

http://git.horde.org/diff.php/imp/lib/Imap.php?rt=horde-git&r1=df8c626194789a61214771c8b5ac07fa870bdc8b&r2=ba5fce1be74c5d90f085e622b806eae53d4acc38
2009-08-06 17:14:03 Michael Slusarz Comment #16
State ⇒ Resolved
Reply to this comment

[Show Quoted Text - 10 lines]
Thanks for the catch - my system is set up so that both are available 
so I didn't notice this.  And thanks for helping to resolve this issue.
2009-08-06 06:33:06 frank (dot) richter (at) hrz (dot) tu-chemnitz (dot) de Comment #14 Reply to this comment
I have to change

   $old_names = array_map('trim', explode("\n", 
Horde_Util::getFormData('old_names')));

   $new_names = array_map('trim', explode("\n", 
Horde_Util::getFormData('new_names')));

to:

   $old_names = array_map('trim', explode("\n", 
Util::getFormData('old_names')));

   $new_names = array_map('trim', explode("\n", 
Util::getFormData('new_names')));



(otherwise it exits - empty page in browser).



With this, yes, it works:

  - renaming folder in INBOX namespace

  - renaming folder within shared namespace

  - renaming a shared folder to INBOX: Give INBOX.foldername as new 
folder name, that's ok.



Thank you very much,

Frank
2009-08-05 21:58:00 CVS Commit Comment #12 Reply to this comment
2009-08-05 21:30:33 frank (dot) richter (at) hrz (dot) tu-chemnitz (dot) de Comment #11 Reply to this comment

[Show Quoted Text - 23 lines]
This is correct IMHO  - at least in our environment no user may create 
toplevel folders

in public namespace, so INBOX.foo.test2 is the only solution.
There are only two ways I can think of to fix:
1. Look at the old mailbox name and only allow a rename within that
namespace.
Would be better than now, but not optimal.
2. Requiring the entire folder name while renaming, but this was what
was specifically refused in the previously mentioned ticket since
personal namespaces should be invisible to the user.
That's right, don't do that.
This is why Cyrus' namespace setup has *never* made sense to me.  The
default namespace should be a user's personal namespace - shared and
other folders are special folders that should live under a specific
sub-folder.
I agree ...

In a GUI this moving of folders between namespaces is easier ...



Frank


2009-08-05 21:29:54 Michael Slusarz Comment #10 Reply to this comment
Re-reading RFC 2342, the assumption seems to be that folders (once 
created) are restricted to that particular namespace.  So we will go 
with option #1.
2009-08-05 21:18:48 Michael Slusarz Comment #9 Reply to this comment

[Show Quoted Text - 19 lines]
What if the user wants to rename 'group.test.test1' to 'foo.test2'.   
It would fall through to your last case and get added as 
'INBOX.foo.test2' which is not correct.



There are only two ways I can think of to fix:

1. Look at the old mailbox name and only allow a rename within that namespace.

2. Requiring the entire folder name while renaming, but this was what 
was specifically refused in the previously mentioned ticket since 
personal namespaces should be invisible to the user.



This is why Cyrus' namespace setup has *never* made sense to me.  The 
default namespace should be a user's personal namespace - shared and 
other folders are special folders that should live under a specific 
sub-folder.
2009-08-05 10:27:44 frank (dot) richter (at) hrz (dot) tu-chemnitz (dot) de Comment #8 Reply to this comment
Take 2 - try this latest patch.  Essentially, it doesn't try to
auto-magically add namespace information.
The same behavior as with the previous patch:

Renaming group.* (namespace '') folder is ok, renaming in INBOX 
namespace is wrong.

I'd like to rename "test" (in INBOX) to "test1",

IMP aks for new name for "test" (not "INBOX.test"), I give "test1"

This leads to:  Rename INBOX.test test1  ->  Permission denied



It's a bit tricky for IMP to detect which namespace a folder should go 
to (if an "empty" namespace '' exists).

An approach might be (pseudo code):



if ($newfolder starts with "non-empty namespace") {

     // INBOX.test1 - should be ok to use $newfolder

} else {

     if ($newfolder doesn't contain delimiter  - '.' im my server) {

         // test1

         $newfolder = defaultnamespace . $newfolder;

     } elseif ($newfolder "starts with existing foldername") {

         // i.e. group.test.test1 ->

         // group.test exists already -> use $newfolder

         // if a user wants to create/rename to INBOX.group.test.test1 
(a rare case IMHO)

         // he has to type INBOX.group.test.test1

     } elseif () {

         // other.folder

         $newfolder defaultnamespace . $newfolder;

     }

}



Frank
2009-08-05 07:48:51 Michael Slusarz Comment #7 Reply to this comment
Take 2 - try this latest patch.  Essentially, it doesn't try to 
auto-magically add namespace information.
2009-08-05 07:47:06 CVS Commit Comment #6 Reply to this comment
2009-08-05 07:03:08 Michael Slusarz Comment #5 Reply to this comment
I knew I had seen this before - this is the same issue as Bug #2874.
2009-08-05 06:47:18 frank (dot) richter (at) hrz (dot) tu-chemnitz (dot) de Comment #4 Reply to this comment
Does this patch fix things?
It fixes renaming the "group.*" folders, but breaks renaming folders in INBOX.

Renaming test to test1 (in INBOX) leads to IMAP command

Rename INBOX.test test1  ->  Permission denied



Thanks,

Frank
2009-08-05 03:57:01 Michael Slusarz Comment #3
State ⇒ Feedback
Milestone ⇒ 4.3.5
Reply to this comment
Does this patch fix things?
2009-08-05 03:56:39 CVS Commit Comment #2 Reply to this comment
2009-08-03 15:31:37 Jan Schneider Assigned to Michael Slusarz
State ⇒ Assigned
 
2009-07-31 14:40:14 frank (dot) richter (at) hrz (dot) tu-chemnitz (dot) de Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Summary ⇒ Renaming public folder is wrong
Queue ⇒ IMP
Milestone ⇒
Patch ⇒ No
Reply to this comment
Hi,

we have a IMAP server (cyrus) with this namespace:

   NAMESPACE (("INBOX." ".")) (("user." ".")) (("" "."))



We've so-called group mailboxes, aka group.test.folder1

Renaming such a  folder within IMP's folder screen moves this folder 
below user's INBOX, i.e.

   rename group.test.folder1 to group.test.folder2

leads to INBOX.group.test.folder2, but not to group.test.folder2



IMAP command is

    Rename group.test.folder1 INBOX.group.test.folder2



Any help is appreciated.



Regards,

Frank




Saved Queries