6.0.0-alpha10
▾
Tasks
New Task
Search
Photos
Wiki
▾
Tickets
New Ticket
Search
dev.horde.org
Toggle Alerts Log
Help
5/15/25
H
istory
A
ttachments
C
omment
W
atch
Download
Comment on [#10470] full creator permissions on a calendar "all authenticated" can show+read does not imply add privileges
*
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
N
ew Ticket
M
y Tickets
S
earch
Q
uery Builder
R
eports
Saved Queries
Open Bugs
Bugs waiting for Feedback
Open Bugs in Releases
Open Enhancements
Enhancements waiting for Feedback
Bugs with Patches
Enhancements with Patches
Release Showstoppers
Stalled Tickets
New Tickets
Horde 5 Showstoppers