Access control

[boonebgorges]

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.

[r-a-y]

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).

[boonebgorges]

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 https://github.com/boonebgorges/buddypress-docs/pull/444 for a similar feature in buddypress-docs. Does this seem right to you @r-a-y ?

[r-a-y]

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.

[r-a-y]

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]

+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 https://github.com/cuny-academic-commons/bp-event-organiser/issues/5#issuecomment-89824678.

[r-a-y]

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