Tickets :: [#10470] full creator permissions on a calendar "all authenticated" can show+read does not imply add privileges

6.0.0-alpha10

5/14/25

Summary	full creator permissions on a calendar "all authenticated" can show+read does not imply add privileges
Queue	Kronolith
Queue Version	3.0.7
Type	Bug
State	Assigned
Priority	1. Low
Owners	Horde Developers (at) , jan (at) horde (dot) org
Requester	ralf.lang (at) ralf-lang (dot) de
Created	08/31/2011 (5005 days ago)
Due
Updated	09/09/2015 (3535 days ago)
Assigned	11/30/2011 (4914 days ago)
Resolved
Milestone
Patch	No

09/09/2015 08:17:26 PM	marcoep (at) gmail (dot) com	Comment #7	Reply to this comment
Same problem with H5 (4.2.5). Is there any progress or workaround?

03/18/2014 01:46:22 PM	gimili17 (at) gmail (dot) com	Comment #6	Reply to this comment
I just had someone edit an event they did not create so as far as I can tell this is still an issue as of March 2014 and Kronolith 4.1.5 but it is also possible I am missing something? As far as I can tell you can't assume events you add are not changed. With drag and drop events, it is easy to accidently change an event you do not own by dragging it to a different day. I think people are not aware of this bug when they setup shared calendars. It would probably be a lot of work but a "create" or "add new" option seperate from "edit" would be really sweet. Even if authenticated users lost the "edit" and "delete" permissions for events they do not own, that would be great as well. Thank you kindly.

11/27/2012 07:18:14 PM	vsz (at) punk (dot) oc (dot) chemie (dot) tu-darmstadt (dot) de	Comment #5	Reply to this comment
[Show Quoted Text - 16 lines][Hide Quoted Text] OK I just tested kronolith 3.0.16 traditional view and with Authenticated Users: show, read, delegate Creator as show, read, edit, delete, delegate Result: Nobody can add new events. With Authenticated Users: show, read, edit, delegate Creator as show, read, edit, delete, delegate Result: users can now create new events and only delete events that they own. The problem is users can still edit events that they did not create yet if I remove the edit for authenticated users then they can't create any events. Thanks for the suggestion Ralf as this is a big improvement as at least users can no longer delete events that they did not create. I just upgraded from H4 to Kronolith H5 4.0.1 and the behaviour described above is still present. In traditional view as well as in dynamic view and for both system and standard user calendars. Has there been progress with this over the last year? Are there new workarounds?

04/12/2012 12:01:39 PM	gimili17 (at) gmail (dot) com	Comment #4	Reply to this comment
OK I just tested kronolith 3.0.16 traditional view and with Authenticated Users: show, read, delegate Creator as show, read, edit, delete, delegate Result: Nobody can add new events. With Authenticated Users: show, read, edit, delegate Creator as show, read, edit, delete, delegate Result: users can now create new events and only delete events that they own. The problem is users can still edit events that they did not create yet if I remove the edit for authenticated users then they can't create any events. Thanks for the suggestion Ralf as this is a big improvement as at least users can no longer delete events that they did not create.

11/30/2011 05:51:06 PM	Jan Schneider	Assigned to Jan Schneider Assigned to Horde Developers State ⇒ Assigned

09/01/2011 11:28:08 AM	michael (dot) menge (at) zdv (dot) uni-tuebingen (dot) de	Comment #3	Reply to this comment
I had the same problem, but it was left unanswered http://bugs.horde.org/ticket/4021

08/31/2011 04:09:23 PM	gimili17 (at) gmail (dot) com	Comment #2	Reply to this comment
How it worked in Horde 3 and how it's still supposed to work in Horde 4, is that setting creator permissions implicitly sets add permissions too. Doesn't work for me either. Perhaps consideration should also be given to changing the tick box label from "Edit" to "Edit/Add" for the creator permissions.

08/31/2011 02:29:48 PM	Ralf Lang	Comment #1 Priority ⇒ 1. Low Type ⇒ Bug Summary ⇒ full creator permissions on a calendar "all authenticated" can show+read does not imply add privileges Queue ⇒ Kronolith Milestone ⇒ Patch ⇒ No State ⇒ Unconfirmed	Reply to this comment
See also mailing list. As you describe the intendedbehaviour I assume this is a bug. If you think the slightly dated version 3.0.7 is an issue I'll verify against git. [Show Quoted Text - 11 lines][Hide Quoted Text] Well yes, it's logical. The creator of an event has permission [xyz] but an event that doesn't exist has no creator. I still have to figure how that works. Probably we're missing something here. It's not a bleeding-edge new thing after all. How it worked in Horde 3 and how it's still supposed to work in Horde 4, is that setting creator permissions implicitly sets add permissions too. So even if not all authenticated users have write permissions, they all have add permissions as soon as they have creator permissions. Jan. Actually no, and it seems to be consistent between traditional and ajax view. test setup: login admin. create system calendar "permstest" Setup matrix: all auth gets show + read normal user "testuser1" gets no on calendar perms object creator gets full perms logout admin. login testuser1 (traditional) create event. Dropdown "calendar" doesn't offer 'permstest' change to ajax create event Dropdown "calendar" doesn't offer 'permstest'