| Summary | Standard share dialog and Kolab access rights |
| Queue | Kronolith |
| Queue Version | Git master |
| Type | Enhancement |
| State | Accepted |
| Priority | 1. Low |
| Owners | |
| Requester | thomas.jarosch (at) intra2net (dot) com |
| Created | 02/07/2013 (4479 days ago) |
| Due | |
| Updated | 01/27/2016 (3395 days ago) |
| Assigned | 03/01/2013 (4457 days ago) |
| Resolved | |
| Milestone | |
| Patch | No |
State ⇒ Accepted
Priority ⇒ 1. Low
permissions. Kolab would then habe a combined edit/delete permission.
(obviously) would render the DELETE permission useless and allow
anyone with EDIT permissions to delete objects.
The way Kolab works we need the Delete IMAP ACL for the EDIT permission.
State ⇒ Feedback
(obviously) would render the DELETE permission useless and allow
anyone with EDIT permissions to delete objects.
New Attachment: 0001-Fix-Horde_Perms-EDIT-permission-for-Kolab-12025.patch
Patch ⇒ Yes
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ Standard share dialog and Kolab access rights
Queue ⇒ Kronolith
Milestone ⇒
Patch ⇒ No
State ⇒ Unconfirmed
the standard "share" dialog of kronolith offers two share modes:
"read the events" and "read and edit the events".
For Kolab the "read and edit the events" gets mapped
to these IMAP ACLs: "lrswikxc".
-> The delete right 'd' is missing.
When one tries to edit an event or move it, the user is presented a
red "Permission denied" box.
To make things worse, the move of an event creates a duplicate entry
on the server without aborting the whole "transaction". (I guess we
create the new entry first and then try to delete the old one. I
haven't looked at the code yet).
Question about the Horde -> Kolab ACL mapping:
Should we add the delete access right if "edit" rights are given for a share?
The way Kolab works we need this to "update" an object.
Thomas