[#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, jan@horde.org
Requester lang@b1-systems.de
Created 2011-08-31 (3344 days ago)
Due
Updated 2015-09-09 (1874 days ago)
Assigned 2011-11-30 (3253 days ago)
Resolved
Milestone
Patch No

Comments
"Ralf Lang (B1 Systems GmbH)" <lang@b1-systems.de> 2011-08-31 14:29:48
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.

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

gimili17@gmail.com 2011-08-31 16:09:23
>> 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.



michael.menge@zdv.uni-tuebingen.de 2011-09-01 11:28:08
I had the same problem, but it was left unanswered

http://bugs.horde.org/ticket/4021

gimili17@gmail.com 2012-04-12 12:01:39
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.

vsz@punk.oc.chemie.tu-darmstadt.de 2012-11-27 19:18:14
> 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?

gimili17@gmail.com 2014-03-18 13:46:22
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.

marcoep@gmail.com 2015-09-09 20:17:26
Same problem with H5 (4.2.5). Is there any progress or workaround?