Cms events gets

[Tech-lo]

The two CMS GET endpoints reuse our standard CMS permission helpers (require_can_read_group_content for get-one, and group-scoping for the list). Super admins and reviewers see everything; normal users are scoped to their own groups. No new permission logic was added as same rules as plans/other CMS content.

[greptile-apps]

Confidence Score: 4/5

The membership-scoped list path has a revocation race that should be fixed before merging.

• Detail reads apply the established group permission helper.
• List filters are applied consistently to result and count queries.
• Separate membership and event queries can expose revoked-group content during a concurrent update.

pecha_api/events/event_service.py

Security Review

The list path reads group membership and events in separate database sessions. A concurrent membership revocation can allow one request to return content from the revoked group.

_{Reviews (1): Last reviewed commit: "Merge remote-tracking branch 'origin/dev..." | Re-trigger Greptile}

[greptile-apps]

Membership Revocation Race

For a normal author, group IDs are read in this session but events are fetched later in a separate session. If membership is revoked between those reads, the event query still uses the stale group IDs and can return content from the revoked group.

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
2.7% Duplication on New Code

See analysis details on SonarQube Cloud