Permissions are working now. Thanks Jan and Gunnar.

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.

Changes have been made in Git (master):

commit f04ce7db09f0230ba531cad3e7ce51b8ecbddd3b
Author: Jan Schneider <jan@horde.org>
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

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.

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.

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

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.

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.

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

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