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

Search Results: 5 of 126 [ <<First <Prev Next> Last>> ] [ Return to Search Results ]

* Your Email Address
* Spam protection	Enter the letters below: .__ .__ . ..__ .___. [__)[__)\|\ \|[__) \| \| \[__)\| \\|[__) \|
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. > >> > 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'
Attachment
Watch this ticket