6.0.0-git
2019-03-23

[#12025] Standard share dialog and Kolab access rights
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 2013-02-07 (2235 days ago)
Due
Updated 2016-01-27 (1151 days ago)
Assigned 2013-03-01 (2213 days ago)
Resolved
Milestone
Patch No

History
2016-01-27 17:01:55 Jan Schneider Type ⇒ Enhancement
State ⇒ Accepted
Priority ⇒ 1. Low
 
2013-08-27 10:40:06 Jan Schneider Comment #5 Reply to this comment
We probably need the share backends to provide the list of available 
permissions. Kolab would then habe a combined edit/delete permission.
2013-03-06 10:35:20 Thomas Jarosch Comment #4 Reply to this comment
I don't feel comfortable at all with this change, because this 
(obviously) would render the DELETE permission useless and allow 
anyone with EDIT permissions to delete objects.
Any other idea?

The way Kolab works we need the Delete IMAP ACL for the EDIT permission.

2013-03-01 17:03:57 Jan Schneider Comment #3
State ⇒ Feedback
Reply to this comment
I don't feel comfortable at all with this change, because this 
(obviously) would render the DELETE permission useless and allow 
anyone with EDIT permissions to delete objects.
2013-02-13 14:38:52 Thomas Jarosch Comment #2
Patch ⇒ Yes
New Attachment: 0001-Fix-Horde_Perms-EDIT-permission-for-Kolab-12025.patch Download
Reply to this comment
Patch to fix the issue.

2013-02-07 16:33:26 Thomas Jarosch Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ Standard share dialog and Kolab access rights
Queue ⇒ Kronolith
Milestone ⇒
Patch ⇒ No
Reply to this comment
Hi,

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

Saved Queries