Perché esiste questo modello
La collaborazione payroll ha un impatto reale sulla sicurezza. Un modello di ruoli facile da leggere, testare e auditare è più sicuro di un modello fatto di controlli isolati.
La struttura Organization <-> Member assegna a ogni attore una relazione esplicita con un’organizzazione con comportamento di stato, ruolo e scope consapevole della policy.
Modifiche alla relazione Organization <-> Member
- La membership è rappresentata come relazione esplicita invece che come stato implicito della UI.
- Gli stati di richiesta accesso, invito, approvazione, attivazione e revoca sono applicati dalla policy backend.
- Pannelli e notifiche dell’organizzazione riflettono transizioni e risultati dei ruoli in modo più coerente.
- Il comportamento condiviso dell’organizzazione è governato dallo stato di membership prima delle azioni privilegiate.
Modifiche ai ruoli e filosofia corrente
I ruoli sono guidati dalle capability, con restrizioni di scope applicate per operazione. La baseline corrente:
- owner: sovereign control including ownership transfer and high-trust governance actions.
- manager: day-to-day operational control without ownership transfer authority.
- contributor: trusted operator with write authority constrained by assigned scope.
- member: limited self-service participation with restricted mutation rights.
- viewer: read-only visibility without write permissions.
Preferiamo composizione esplicita di capability e scope rispetto a flag di ruolo sovraccarichi. Questo rende i risultati più facili da testare e ragionare.
Filosofia di sicurezza e cifratura
La collaborazione organizzativa si intreccia con cifratura e controlli di consenso. I controlli membership e ruolo regolano il comportamento envelope condiviso affinché le operazioni sensibili restino vincolate alla policy.
- Membership e consenso sono validati prima delle operazioni sicure condivise.
- Cambi di ruolo e transizioni di membership sono eventi rilevanti per la sicurezza, non solo UX.
- I percorsi di accesso negato sono comportamento previsto in caso di mismatch policy e sono esposti per auditabilità.
Filosofia operativa futura
- Single policy source: role and scope decisions should originate from shared backend policy maps.
- UI as projection: interfaces should display policy outcomes rather than duplicate authorization logic.
- Traceable transitions: approvals, role changes, and revocations should remain observable and reviewable.
- Release transparency: behavior changes in membership and roles are documented in changelogs and transparency pages.