The Ranks & Roles "Operational Permission Matrix" previously waited ~400ms and
showed a "Saved" state without persisting anything. No Firestore document, API
route, or security rule stores or enforces a per-rank capability matrix; club
authorization is role-based (Owner/Admin via getPortalPermissions). Persisting
the matrix would require frozen security-rule changes and would create an
unenforced permission model that misleads owners.
Make the control truthful instead of faking success:
- Render the matrix as a read-only reference of the standard governance model
by default (persistenceAvailable=false): no Save/Reset controls, disabled
toggles, a "View-only reference" indicator, and a notice stating that access
is enforced by Owner/Admin roles and per-rank customization is planned.
- Remove the fake setTimeout save handler and the unconditional success state.
- Retain a forward-compatible editable path behind persistenceAvailable for
when a backend contract ships.
- Document the precise backend contract required to enable persistence.
Tests: read-only matrix renders no Save control, reports no save, and does not
mutate permissions even for Owner/Admin; editable path still fires toggle/save
/reset when persistenceAvailable=true.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* feat(clubs): enable admin group ride governance
* feat(clubs): add secure member ride discovery
* fix(clubs): protect meeting location in ride discovery
* feat(group-rides): secure club join moderation
* test(clubs): update ride discovery expectations
* test(founder-portal): update rides governance expectations
* fix(group-rides): resolve pre-merge findings on join moderation and discovery
- Block participant hard deletes for accepted status and organizer role for all callers
- Support atomic accessUids removal on invitation decline in firestore.rules
- Restrict mutual-block checks to approvals in GroupRideService, allowing decline of blocked requests
- Implement cursor-paginated candidate scanning with block filtering in website discovery API
- Add comprehensive emulator, vitest, and unit tests covering all 5 findings
* fix(discovery): page candidates until 30 eligible rides collected or query exhausted
- Remove artificial 150 candidate scan ceiling in club rides discovery route
- Continue cursor pagination until 30 unblocked eligible rides are collected or upcoming schedule query is exhausted
- Add test verifying pagination continues past 150 blocked rides to collect all 30 eligible rides
---------
Co-authored-by: Developer <dev@example.com>
Add the disabled Founder Portal Club Rides scaffold aligned with the live GroupRide.clubId domain.
Keep production discovery and actions disabled until a privacy-preserving read path and real management destinations are implemented.
- Gate ranks-roles management route on canManageSettings with safe
unauthorized state, matching sibling founder-management routes
- Enforce HTTPS image URL invariant for club logo/banner in the data
layer (validateClubImageUrl) and in Firestore rules, preserving
null/empty clearing
Developer
Billie Ponder