Suite role sync and permission enforcement follow-ups
Problem
Google login is only the first step for hosted access. After M1 login is working, Suite still needs a clear authorization model: how Google identities map to Suite roles, where permission enforcement lives for project/dashboard actions, and how access drift or audit needs are handled. That work should not block M1 login, but it should be captured explicitly for M2 instead of getting lost as implicit debt.
Context
- Depends on
task-m1-suite-google-auth-permissions-sync.mdlanding a working Google login flow first. - Follow-up scope includes role mapping, permission enforcement boundaries, and access/audit drift handling.
- This task is intentionally deferred to M2 so M1 can focus on authentication, not the full authorization model.
Possible Solutions
- A - Handle permissions piecemeal in each view: fast to patch, but hard to reason about and easy to drift.
- B - Recommended: define one role-sync and permission-enforcement model: map identities to Suite roles centrally, then enforce those permissions consistently across product surfaces.
- C - Over-centralize everything in a complex policy engine first: flexible, but more architecture than this phase needs.
Plan
- Define the minimum viable M2 authorization model for Suite pilot/project access.
- Decide how Google identities or groups map to Suite roles.
- Add permission enforcement checks at the relevant backend and UI boundaries.
- Document operator workflows for access changes, exceptions, and audit/drift handling.
Implementation Progress
QA Exploration
- [ ] QA exploration completed (or N/A for non-UI tasks)
Review Feedback
- [ ] Review cleared