Por que este modelo existe
Colaboração em folha tem impacto real de segurança. Um modelo de papéis fácil de ler, testar e auditar é mais seguro do que verificações isoladas espalhadas.
A estrutura Organization <-> Member dá a cada ator uma relação explícita com uma organização, com comportamento de status, papel e escopo consciente da política.
Mudanças na relação Organization <-> Member
- Membership é representado como relação explícita, não como estado implícito da UI.
- Estados de solicitação de acesso, convite, aprovação, ativação e revogação são aplicados por política backend.
- Painéis e notificações refletem transições de relação e resultados de papéis de forma mais consistente.
- Comportamento compartilhado da organização é governado pelo estado de membership antes de ações privilegiadas.
Mudanças de papéis e filosofia atual
Papéis são guiados por capabilities, com restrições de escopo por operação. A base atual:
- 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.
Preferimos composição explícita de capability e escopo em vez de flags de papel sobrecarregadas. Isso facilita testar e raciocinar sobre resultados.
Filosofia de segurança e criptografia
Colaboração organizacional cruza criptografia e consentimento. Verificações de membership e papel controlam o comportamento compartilhado para manter operações sensíveis vinculadas à política.
- Estado de membership e consentimento é validado antes de operações seguras compartilhadas.
- Mudanças de papel e transições de membership são eventos relevantes para segurança, não só UX.
- Caminhos de negação de acesso são comportamento esperado sob mismatch de política e ficam visíveis para auditoria.
Filosofia operacional daqui em diante
- 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.