Repository navigation
Private group events are readable by anyone #134
Description
hc-custom's capability mapping for Event Organiser grants read_private_events to every user, including anonymous visitors. The handler treats it as a cap with no event context and falls through to the branch that returns exist.
Because Event Organiser's calendar queries rely on that capability (via WP_Query's perm => readable) to decide whether private posts are visible, events belonging to private and hidden groups, which are stored as private posts, come back for anyone who asks. Reproduced on the local test stack: an anonymous request to the calendar's AJAX endpoint returned a private group's event alongside the public ones.
The cap should keep WordPress's role-based mapping. Group members still need to see their group's private events on the group calendar, so the group-scoped calendar query should rely on its own group-membership check rather than on this capability.
Activity
fix(hc-custom): stop granting read_private_events to everyone
MartinPaulEve commentedon Oct 4, 2026
Came out of review on #133. The capability handler was answering "yes" to read_private_events for everyone because it had no event to check against, and Event Organiser leans on that cap when deciding whether private events show up in calendar queries. On the test stack an anonymous request to the calendar endpoint returned a private group's event.
Fixed in the same branch: the cap now keeps its normal role-based meaning, and the calendars check group membership directly instead. Members still see their own groups' private events, both on the group calendar and on the sitewide one; nobody else does.
feat(hc-custom): show members their private groups' events sitewide
fix(hc-custom): keep full private-event access for roles that have it
perf(hc-custom): restrict members' private events in SQL, not by ID list
bjr70 commentedon Oct 4, 2026
Fixed