Unidades y equipos

Las unidades y equipos modelan membresía anidada dentro de una organización:

organization
└── unit
    └── team

Úsalas cuando un departamento o grupo de trabajo estable necesite su propio destino de compartir o alcance administrativo. Los grupos suelen ser más simples para compartir ad hoc.

Roles almacenados

unit_admin y team_lead tienen autoridad definida de gestión de membresía en la API de organizaciones. Las etiquetas creator/approver/deployer expresan responsabilidades de flujo previstas, pero su presencia no prueba aplicación por cada endpoint de compilación o despliegue. Prueba el flujo concreto.

Reglas de membresía

• Una unidad pertenece a una organización.
• Un equipo pertenece a una unidad.
• Un usuario debe ser miembro de la organización antes de unirse a una unidad o equipo.
• Un miembro de equipo debería estar también en la unidad padre; las rutas administrativas aplican la jerarquía al añadir miembros.
• Owners/admins de organización y administradores acotados tienen distintos poderes de gestión, descritos en Roles y alcance de permisos.

Orientación de diseño

Crea una unidad solo si tiene un límite durable como propiedad, responsabilidad de aprobación o un alcance distinto de compartir recursos. Crea un equipo para un grupo de trabajo más pequeño dentro de ese límite.

Ejemplo:

Acme
├── Platform unit
│   ├── Image engineering team
│   └── Security review team
└── Product unit
    └── Device application team

No codifiques un organigrama que no afecte la autorización. Anidar de más aumenta el riesgo de membresías obsoletas y shares heredados inesperados.

Cambios seguros

Para un alta, cambio de rol o baja:

1. registra organización, unidad, equipo, usuario y roles actuales;
2. haz un cambio;
3. prueba una operación permitida;
4. prueba una operación denegada;
5. refresca o reautentica para detectar comportamiento de sesión obsoleta; y
6. revisa shares cuya membresía objetivo cambió.

Los usuarios pueden pertenecer a varias unidades y equipos. Añadir una membresía nueva no transfiere ni elimina una antigua.

Límite de eliminación

Eliminar una unidad o equipo es una operación material. No confíes en afirmaciones genéricas como «los recursos pasan a nivel de unidad» o «los recursos sin asignar se archivan». Antes de eliminar, usa inventario de solo lectura para identificar membresías, shares, recursos dependientes, trabajo activo y referencias externas. Exporta el registro de auditoría requerido y confirma el comportamiento en cascada exacto de la versión desplegada.

Si el impacto no está claro, elimina primero compartir amplio y miembros, conserva el objeto y busca aprobación del owner antes de eliminar.