Membresía de organización y filosofía de roles

Esta página explica el cambio desde una semántica de equipo poco acoplada hacia un modelo explícito de relación Organization <-> Member, la política actual de roles y los principios usados para mantener permisos auditables y seguros.

Por qué existe este modelo

La colaboración en nómina tiene impacto real en seguridad. Un modelo de roles fácil de leer, probar y auditar es más seguro que uno construido con comprobaciones aisladas.

La estructura Organization <-> Member da a cada actor una relación explícita con una organización, con comportamiento de estado, rol y alcance consciente de la política.

Cambios en la relación Organization <-> Member

  • La membresía se representa como una relación explícita en lugar de un estado implícito de UI.
  • Los estados de solicitud de acceso, invitación, aprobación, activación y revocación se aplican por política backend.
  • Los paneles y notificaciones de organización reflejan transiciones y resultados de roles de forma más consistente.
  • El comportamiento compartido de organización se rige por el estado de membresía antes de procesar acciones privilegiadas.

Cambios de roles y filosofía actual

Los roles se basan en capacidades, con restricciones de alcance por operación. La base actual:

  • 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 composición explícita de capacidades y alcance sobre banderas de rol sobrecargadas. Esto hace que los resultados sean más fáciles de probar y razonar.

Filosofía de seguridad y cifrado

La colaboración organizacional se cruza con cifrado y controles de consentimiento. Las comprobaciones de membresía y rol protegen el comportamiento compartido para que las operaciones sensibles sigan sujetas a política.

  • El estado de membresía y consentimiento se valida antes de operaciones seguras compartidas.
  • Los cambios de rol y transición de membresía son eventos relevantes para seguridad, no solo UX.
  • Las rutas de denegación son comportamiento esperado ante desajuste de política y se exponen para auditoría.

Filosofía operativa hacia adelante

  • 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.