Access control #5

boonebgorges · 2015-03-17T18:55:18Z

It should be possible to control access to an event or a calendar based on group membership/role. Here's what I wrote in the original CAC ticket:

Default status for events should be public.

People are going to want to have non-public events. Generally, I assume that "non-public" will mean "visible only to the members of the associated group". This suggests a simple toggle. It gets more complicated if people associate items with more than one group. But I say that for now, we don't worry about that. Either you have a public event, or one that's visible only to members of associated groups. Samantha, your thoughts on this would be welcome.

What does EO currently do for visibility/access? Anything?

We should also control the ability to connect events to groups. This might be a hardcoded meta cap for now (eg, groups_is_user_member()) but at some point this might be configurable by the group admin. BuddyPress Docs, for example, lets you set a minimum group role that a user must have in order to associate Docs with the group.

The text was updated successfully, but these errors were encountered:

r-a-y · 2015-03-17T20:45:35Z

What does EO currently do for visibility/access? Anything?

EO uses meta caps for posting permission:
https://github.com/stephenharris/Event-Organiser/blob/9cb3399ec28561e4a96c61d1cbd97edf538a13fd/includes/event-organiser-cpt.php#L330

In the CAC ticket, I recommended augmenting EO's caps by checking for group member role and adding in EO's native caps.

Visibility, I think, uses WP's native post_status field (publish, private).

See #5.

boonebgorges · 2015-03-23T20:58:25Z

781f500 does the basic 'read' logic.

Regarding editing: @r-a-y, I see that in 1f75c6e you asked some questions about whether mods/members/etc should be able to edit group-connected events. My inclination is to say no: we should let EO handle 'edit_event' mapping https://github.com/stephenharris/Event-Organiser/blob/9cb3399ec28561e4a96c61d1cbd97edf538a13fd/includes/event-organiser-cpt.php#L330, which is to say that only super admins and the event author should be able to edit. I think what we'll probably need is a separate cap/UI for disconnecting an event from a group, and that should be available to group admins/mods. See boonebgorges/buddypress-docs#444 for a similar feature in buddypress-docs. Does this seem right to you @r-a-y ?

r-a-y · 2015-03-23T22:20:54Z

Your suggestions sound good to me.

My inline comments were just reminders to switch those lines out after we've determined who should have access to what.

The previous implementation queried for all events, and then filtered out individual events not belonging to the group using the `intercept_calendar()` filter on 'eventorganiser_fullcalendar_event'. This technique is inefficent, especially as the number of group events increases. The new technique is to detect the 'bp_group_id' param sent with the AJAX request, and then add a corresponding 'bp_group' param to the event query, using the new 'eventorganiser_fullcalendar_query' filter in EO. This mirrors the way user-specific calendar requests are filtered. See #2, #5, #8.

…vent' ). See #5.

r-a-y · 2015-04-05T18:17:20Z

On a default BP install, a user has the 'subscriber' role. If a user attempts to post a new event from their profile, the event will fail.

This is because in EO, the 'subscriber' role does not have publish event privileges by default. However, it is possible for an admin to set these caps for each role in EO's settings panel.

For our needs, I think we should force the 'publish_events' meta cap for all users when a user is on their profile page.

boonebgorges · 2015-04-05T18:21:28Z

+1

On 04/05/15 14:17, r-a-y wrote:

On a default BP install, a user has the |'subscriber'| role. If a user
attempts to post a new event from their profile, the event will fail.

This is because in EO, the |'subscriber'| role does not have publish
event privileges by default. However, it is possible for an admin to set
these caps for each role in EO's settings panel.

For our needs, I think we should force the |'publish_events'| meta cap
for all users when a user is on their profile page.

—
Reply to this email directly or view it on GitHub
#5 (comment).

See #5.

…ibutor' role. Commit also includes unit tests. See #5.

…vent" page. See #5.

Fixes an issue where a user with no default role (but has the bbPress default role of 'bbp_participant') has no ability to publish an event. Previously, the logic was to check if a user explicitly had either the 'contributor' or'subscriber' role. See #5.

- Only query for public events by friends. Have to separate queries for events by the user and a user's friends so the post status is not shared amongst the two. - Add 'private' status when querying for user or group events. See #5.

…caps need access to a specific event ID. The plural caps (the primitives) do not, and PHP notices should be avoided in these cases. See #5.

See #5.

Users: - Do not map caps for 'edit_events' and 'delete_events' caps. These are already mapped to the 'edit_event' and 'delete_event' cap by EO's caps. - Set meta caps for 'edit_event', 'delete_event' and 'read_event'. - Add unit tests for 'delete_event' cap. - Move over user-related tests from group tests. Groups: - Do not map caps for 'edit_event'; this should be handled in the user meta cap function as denoted above. - Bail when there are no groups attached to an event. See #5.

The 'edit_events' cap allows users to create tags and categories. This was removed during a previous cap audit. See commit 88a83f7. See #5.

This allows group members to properly edit and delete their own events. Reverts a portion of commit 88a83f7 and commit adad794. See #5.

See #5.

…ng else. See #5.

Requires dynamically giving admins and mods the 'edit_others_events' capability. See #5.

r-a-y · 2021-11-19T19:39:04Z

Internally, we decided to give group admins and mods the ability to edit and delete events. See commit 37594b7.

boonebgorges self-assigned this Mar 17, 2015

boonebgorges added a commit that referenced this issue Mar 23, 2015

Cap meta mapping for group-connected events.

781f500

See #5.

r-a-y added a commit that referenced this issue Mar 31, 2015

Groups: To edit an event, check access with current_user_can( 'edit_e…

6cf0a89

…vent' ). See #5.

r-a-y changed the title ~~Group-integrated access control~~ Access control Apr 5, 2015

r-a-y added a commit that referenced this issue Apr 6, 2015

Groups: Append 'group' to group meta cap filter.

8cce0ca

See #5.

r-a-y added a commit that referenced this issue Apr 6, 2015

Users: Add basic event caps for users with the 'subscriber' or 'contr…

946cfd9

…ibutor' role. Commit also includes unit tests. See #5.

r-a-y added a commit that referenced this issue Apr 6, 2015

Users: Add 'publish_events' cap before a user can access their "New E…

097ca53

…vent" page. See #5.

boonebgorges mentioned this issue Apr 17, 2015

Improved visibility/privacy workflow #28

Closed

boonebgorges added a commit that referenced this issue May 4, 2015

When mapping meta_cap in groups, don't assume that all event-related …

a69047b

…caps need access to a specific event ID. The plural caps (the primitives) do not, and PHP notices should be avoided in these cases. See #5.

boonebgorges added a commit that referenced this issue May 4, 2015

Another attempt at avoiding PHP notices when doing cap checks in groups.

738797e

See #5.

r-a-y added a commit that referenced this issue May 9, 2015

Caps: Allow users to add tags or categories.

b61cebc

The 'edit_events' cap allows users to create tags and categories. This was removed during a previous cap audit. See commit 88a83f7. See #5.

r-a-y added a commit that referenced this issue May 9, 2015

Caps: Provision proper group caps for editing and deleting events.

62373ff

This allows group members to properly edit and delete their own events. Reverts a portion of commit 88a83f7 and commit adad794. See #5.

r-a-y added a commit that referenced this issue May 10, 2015

Users: Make sure authors can read their own event.

65d69af

See #5.

r-a-y added a commit that referenced this issue May 10, 2015

Groups: If we've already parsed the 'read_event' cap, don't do anythi…

e113d63

…ng else. See #5.

r-a-y added a commit that referenced this issue Nov 19, 2021

Allow group admins and mods to edit events.

37594b7

Requires dynamically giving admins and mods the 'edit_others_events' capability. See #5.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Access control #5

Access control #5

boonebgorges commented Mar 17, 2015

r-a-y commented Mar 17, 2015

boonebgorges commented Mar 23, 2015

r-a-y commented Mar 23, 2015

r-a-y commented Apr 5, 2015

boonebgorges commented Apr 5, 2015

r-a-y commented Nov 19, 2021

Access control #5

Access control #5

Comments

boonebgorges commented Mar 17, 2015

r-a-y commented Mar 17, 2015

boonebgorges commented Mar 23, 2015

r-a-y commented Mar 23, 2015

r-a-y commented Apr 5, 2015

boonebgorges commented Apr 5, 2015

r-a-y commented Nov 19, 2021