6.0.0-git
2018-12-16

[#10470] full creator permissions on a calendar "all authenticated" can show+read does not imply add privileges
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 lang (at) b1-systems (dot) de
Created 2011-08-31 (2664 days ago)
Due
Updated 2015-09-09 (1194 days ago)
Assigned 2011-11-30 (2573 days ago)
Resolved
Milestone
Patch No

History
2015-09-09 20:17:26 marcoep (at) gmail (dot) com Comment #7 Reply to this comment
Same problem with H5 (4.2.5). Is there any progress or workaround?
2014-03-18 13:46:22 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.
2012-11-27 19:18:14 vsz (at) punk (dot) oc (dot) chemie (dot) tu-darmstadt (dot) de Comment #5 Reply to this comment

[Show Quoted Text - 16 lines]
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?
2012-04-12 12:01:39 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.
2011-11-30 17:51:06 Jan Schneider Assigned to Jan Schneider
Assigned to Horde DevelopersHorde Developers
State ⇒ Assigned
 
2011-09-01 11:28:08 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
2011-08-31 16:09:23 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.


2011-08-31 14:29:48 Ralf Lang (B1 Systems GmbH) Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ full creator permissions on a calendar "all authenticated" can show+read does not imply add privileges
Queue ⇒ Kronolith
Milestone ⇒
Patch ⇒ No
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]
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'

Saved Queries