Kolab backend: Newly created calendars lose all permissions

Hi, newly created calendars in kronolith lose all IMAP pe

Thu, 15 Nov 2012 13:41:30 +0000

Hi, newly created calendars in kronolith lose all IMAP permissions. I can only see the implicit rights provided by cyrus imapd: lkxca Creating new shares in mnemo/nag works fine. When I repair the ACLs via imp, even the Kolab folder type annotation was set correctly during the creation. Side note: For testing trean, I played around with the permissions backend. I made sure it's disabled now as it was a few days ago and also cleared all caches (horde, browser, PHP sessions). Thomas

I've banging my head for hours against this and cannot find

Thu, 15 Nov 2012 18:02:07 +0000

I've banging my head for hours against this and cannot find out why this only happens in Kronolith. Also, the ACL-permission-mapping for Kolab is broken IMO. See attached patch that gets rid of creator permissions and fixes the ACLs for ALL permissions. Kolab (or IMAP for that matter) doesn't support anything like what "creator" means in Horde, so don't try to map this to the folder creator (share "owner" in Horde).

Fresh day, fresh eyes. I also took at look at this by compar

Fri, 16 Nov 2012 08:57:36 +0000

Fresh day, fresh eyes. I also took at look at this by comparing the mnemo and the kronolith Kolab drivers. -> I couldn't spot a big difference. So I started to add "exit(0)" statements to the addShare() function in kronolith and see where the permissions get lost. Here's a quick "fix" for the issue: diff --git a/kronolith/lib/Ajax/Application/Handler.php b/kronolith/lib/Ajax/Application/Handler.php index d8ba110..e985696 100644 --- a/kronolith/lib/Ajax/Application/Handler.php +++ b/kronolith/lib/Ajax/Application/Handler.php @@ -954,7 +954,7 @@ class Kronolith_Ajax_Application_Handler extends Horde_Core_Ajax_Application_Han } try { $calendar = Kronolith::addShare($info); - Kronolith::readPermsForm($calendar); + // Kronolith::readPermsForm($calendar); if ($calendar->hasPermission($GLOBALS['registry']->getAuth(), Horde_Perms::SHOW)) { $wrapper = new Kronolith_Calendar_Internal(array('share' => $calendar)); $result->saved = true; Wild guess: The "Create calendar" dialog does not show a permission form. kronolith::readPermsForm() doesn't find any set rights and therefore removes all ACLs.

Since the affected code is in "kronolith/lib/Ajax/Applicatio

Fri, 16 Nov 2012 09:02:54 +0000

Since the affected code is in "kronolith/lib/Ajax/Application/Handler.php", I thought it might be nice to try to non-AJAX version of kronolith. -> Permissions are fine in traditional kronolith.

> Wild guess: The "Create calendar" dialog does not show a p

Fri, 16 Nov 2012 10:16:11 +0000

> Wild guess: The "Create calendar" dialog does not show a permission > form. kronolith::readPermsForm() doesn't find any set rights and > therefore removes all ACLs. No. This also happens when using the shares dialog in the basic view. And the permission form *is* submitted from dynamic view, it's only hidden by default - see the advanced sharing tab in the calendar dialog.

> No. This also happens when using the shares dialog in the

Fri, 16 Nov 2012 11:31:23 +0000

> No. This also happens when using the shares dialog in the basic view. > And the permission form *is* submitted from dynamic view, it's only > hidden by default - see the advanced sharing tab in the calendar > dialog. When I open the "advanced sharing" tab without creating anything in the backend yet, the "Object creator" (=IMAP folder owner) doesn't have any rights set. Is that by design?

>> No. This also happens when using the shares dialog in the

Fri, 16 Nov 2012 12:39:56 +0000

>> No. This also happens when using the shares dialog in the basic view. >> And the permission form *is* submitted from dynamic view, it's only >> hidden by default - see the advanced sharing tab in the calendar >> dialog. > > When I open the "advanced sharing" tab without creating anything in > the backend yet, > the "Object creator" (=IMAP folder owner) doesn't have any rights > set. Is that by design? > See my earlier comment. These shouldn't be mapped to each other at all. While tracing down what the problem with Kronolith is, I noticed that the current folder ACL is not correctly retrieved, which is reflected to the permissions screen, like you noticed too. So mapping permissions to ACLs isn't working in either direction.

The analysis from Thomas is correct: The section "// Process

Thu, 22 Nov 2012 18:32:59 +0000

The analysis from Thomas is correct: The section "// Process creator permissions." within Kronolith::readPermsForm currently removes all creator permissions. I'm totally fine with removing the permission mapping between "creator" and "share owner". There is no correct mapping between the Horde permission world and the Kolab permission world at the moment. The question is how much the removal of the creator permission mapping would impair usability. Would it still be displayed even with the Kolab backend and even though any setting there has no effect? Of course the current Kronolith "DELEGATE" permission currently has the same problem. In the long run one would probably need to modify Horde so that it allows for different permission models depending on the selected backend. But I guess that would be a major undertaking. Right now I don't see how I can fix anything here. I could apply Jan's fix but would rather leave that to him.

Changes have been made in Git (master): commit f04ce7db09f0

Wed, 05 Dec 2012 18:23:01 +0000

Changes have been made in Git (master): commit f04ce7db09f0230ba531cad3e7ce51b8ecbddd3b Author: Jan Schneider Date: Wed Dec 5 19:22:39 2012 +0100 [jan] Remove creator permission mapping from Kolab backend (Bug #11713). .../Perms/lib/Horde/Perms/Permission/Kolab.php | 14 +++- .../Horde/Perms/Permission/Kolab/Acl/Creator.php | 43 ---------- .../Horde/Perms/Permission/Kolab/AclIterator.php | 11 +-- .../Perms/Permission/Kolab/Element/Creator.php | 81 -------------------- .../Perms/Permission/Kolab/ElementIterator.php | 21 +++--- framework/Perms/package.xml | 14 +-- framework/Perms/test/Horde/Perms/KolabTest.php | 72 +----------------- 7 files changed, 31 insertions(+), 225 deletions(-) http://git.horde.org/horde-git/-/commit/f04ce7db09f0230ba531cad3e7ce51b8ecbddd3b

This fixes usage of creator permissions from Kolab backends.

Wed, 05 Dec 2012 18:24:11 +0000

This fixes usage of creator permissions from Kolab backends. In another step we need to adapt the permissions screens to only show supported permissions, but that's a different issue.

Permissions are working now. Thanks Jan and Gunnar.

Thu, 06 Dec 2012 10:38:43 +0000

Permissions are working now. Thanks Jan and Gunnar.