Grupos anidados

Un grupo puede ser miembro de otro grupo. Así puedes representar tu organización tal como es: equipos dentro de departamentos, departamentos dentro de divisiones. La pertenencia fluye hacia arriba: quien pertenece a un equipo también pertenece al departamento que lo contiene.

Un ejemplo

Tu departamento de ingeniería tiene dos equipos. Creas tres grupos y añades “Backend” y “Frontend” como miembros de “Ingeniería”:

Ingeniería
├── Backend        ← grupo, miembro directo de Ingeniería
│   ├── Ana        ← miembro directo de Backend, miembro indirecto de Ingeniería
│   └── Bruno
├── Frontend       ← grupo, miembro directo de Ingeniería
│   └── Carla
└── Diego          ← miembro directo de Ingeniería

El resultado:

• Ana, Bruno y Carla son miembros indirectos de “Ingeniería”: pertenecen a él a través de su equipo.
• Diego es miembro directo solo de “Ingeniería”.
• Una aplicación asignada a “Ingeniería” está disponible para Ana, Bruno, Carla y Diego.
• Una aplicación asignada a “Backend” solo está disponible para Ana y Bruno.

Cuando Ana se incorpora a la empresa, basta con añadirla a “Backend”: recibe automáticamente todo lo que ofrece “Ingeniería”. Cuando se cambia al equipo de frontend, muévela de “Backend” a “Frontend” y su acceso la acompaña.

Miembros directos e indirectos

En la pestaña Miembros de un grupo, la columna Asignación distingue ambos casos:

• Directa: se añadió a este grupo explícitamente.
• Indirecta: pertenece a este grupo por ser miembro, en cualquier nivel, de uno de sus grupos miembros.

El anidamiento puede tener tantos niveles como necesites: si “Ingeniería” es miembro de “Tecnología”, Ana también es miembro indirecto de “Tecnología”. Marca Mostrar solo las asociaciones directas para ver solo lo que se añadió al grupo explícitamente.

Un miembro puede pertenecer de varias formas

La misma persona puede pertenecer a un grupo de más de una forma: directamente y a través de un equipo, o a través de dos equipos distintos. BreezeAuth tiene en cuenta cada camino. La persona sigue siendo miembro, y conserva el acceso del grupo, mientras quede al menos un camino.

Por ejemplo, si Diego es miembro directo de “Ingeniería” y además se le añade a “Backend”:

• quitarlo de “Backend” lo mantiene en “Ingeniería” como miembro directo;
• quitar su pertenencia directa a “Ingeniería” lo mantiene en “Ingeniería” como miembro indirecto, a través de “Backend”.

Quitar miembros

Solo se pueden quitar de un grupo los miembros directos. Para terminar una pertenencia indirecta, actúa en su origen:

• quita a la persona del grupo miembro al que pertenece (Ana de “Backend”), o
• quita el propio grupo miembro del grupo (“Backend” de “Ingeniería”). Todos los miembros de ese grupo dejan de ser miembros indirectos, salvo que pertenezcan de otra forma.

Reglas

Para mantener la estructura coherente, BreezeAuth rechaza los cambios que crearían un ciclo:

• un grupo no puede añadirse a sí mismo;
• un grupo no puede añadirse a uno de sus propios miembros, en cualquier nivel. Si “Backend” está en “Ingeniería”, “Ingeniería” no puede añadirse a “Backend” ni a ningún grupo dentro de “Backend”.

Efecto en el acceso a las aplicaciones

Los miembros indirectos reciben el mismo acceso a aplicaciones que los directos. Cuando alguien inicia sesión en una aplicación, BreezeAuth tiene en cuenta todos los grupos a los que pertenece, directa o indirectamente. Consulta Acceso a aplicaciones.

También funciona en sentido contrario: la pestaña Aplicaciones asignadas de “Backend” muestra solo las aplicaciones asignadas al propio “Backend”, pero sus miembros también tienen acceso a las aplicaciones asignadas a “Ingeniería”, el grupo que lo contiene.

Efecto en los webhooks

Si usas webhooks, BreezeAuth envía un evento group_assignment.created por cada nueva pertenencia, también las indirectas. Añadir “Backend” a “Ingeniería” envía un evento por la entrada de “Backend” en “Ingeniería” y otro por cada miembro de “Backend” que pasa a ser miembro de “Ingeniería”. Lo mismo ocurre con group_assignment.deleted cuando terminan las pertenencias.

No se envía ningún evento cuando una pertenencia solo cambia de directa a indirecta, o al revés, porque el miembro sigue perteneciendo al grupo.

Buenas prácticas

• Mantén la estructura poco profunda. Dos o tres niveles, como división › departamento › equipo, suelen bastar y son fáciles de entender.
• Pon a las personas en el grupo más específico. Añade a Ana a “Backend”, no a “Backend” y a “Ingeniería”. Ya pertenece a “Ingeniería” a través de su equipo.
• Asigna las aplicaciones en el nivel adecuado. Las aplicaciones que necesita todo el departamento van en el grupo del departamento; las herramientas propias de un equipo, en el grupo del equipo.