# Roles y permisos

Quién puede hacer qué en la consola, y qué datos ve cada empleado.

# Roles y scope: las dos ideas

> **Dirigido a:** administradores de la plataforma que deciden quién puede hacer qué en la consola.
> **Necesitas:** las secciones Asignaciones y Scope, disponibles para `admin` y `employee_manager`.

El acceso en la consola se basa en dos ideas independientes. Mantenerlas separadas es la clave de todo el modelo.

| Concepto | Qué define | Dónde se configura |
|---|---|---|
| **Roles** | Lo que un empleado **puede hacer** — acciones y módulos | Asignado al empleado; uno o varios |
| **Scope** | Qué datos **puede ver** — marcas, tiendas, fuentes | Configurado una sola vez, por empleado |

Un empleado puede tener varios roles a la vez. Los permisos de todos ellos se combinan. El scope, en cambio, es siempre **compartido**: se aplica por igual a todo lo que ese empleado puede hacer.

## Por qué importa esta separación

Significa que nunca tienes que elegir entre "puede operar el hub" y "solo puede ver dos tiendas". Se responden por separado:

- Le das `hub_operator` → puede trabajar en el hub.
- Configuras su scope a las tiendas 1 y 2 → solo verá los datos de esas dos tiendas, en el hub y en todo lo demás.

Añadir más adelante un segundo rol —informes, por ejemplo— no amplía los datos que ve. El scope se mantiene.

## Las tres cosas que vas a configurar

| Si quieres… | Ve a |
|---|---|
| Permitir que alguien haga algo nuevo | [Gestionar roles desde la consola](/books/console/page/gestionar-roles-desde-la-consola) |
| Cambiar qué datos puede ver | [Configurar el scope de un empleado](/books/console/page/configurar-el-scope-de-un-empleado) |
| Conceder o bloquear una capacidad concreta, solo para esa persona | [Excepciones individuales de permisos](/books/console/page/excepciones-individuales-de-permisos) |

Los roles deciden qué puede hacer alguien; su ficha de personal es cosa aparte — ver [Empleados: qué cubre esta área](/books/console/page/empleados-que-cubre-esta-area).

## Dónde seguir

- [Scope: qué datos puede ver un empleado](/books/console/page/scope-que-datos-puede-ver-un-empleado) — los dos modos y las tres dimensiones
- [Catálogo de roles](/books/console/page/catalogo-de-roles) — cada rol y para quién es
- [Acceso por sección](/books/console/page/acceso-por-seccion) — la rejilla completa de rol contra sección de la consola

# Scope: qué datos puede ver un empleado

Cada empleado tiene un único scope, que controla qué datos ve en toda la consola.

## Los dos modos

| Modo | Qué significa |
|---|---|
| **Customer** | Acceso completo a todos los datos de toda la cadena |
| **Explicit** | Acceso restringido a marcas, tiendas y/o fuentes específicas |

## Las tres dimensiones de un scope explícito

Cuando el scope es explícito, se pueden combinar estos filtros:

| Dimensión | Qué filtra | Ejemplo |
|---|---|---|
| **Marcas** | Qué marcas son visibles | Solo la marca "X" |
| **Tiendas** | Qué tiendas concretas son visibles | Tiendas 1, 2 y 5 |
| **Fuentes** | Qué fuentes de pedido son visibles | Solo Glovo y Uber Eats |

**Cómo se combinan:**

- Cada dimensión reduce más la vista: se acumulan, nunca se amplían entre sí.
- Dejar una dimensión vacía significa "sin restricción" para esa dimensión.
- Las agrupaciones de tiendas —conjuntos predefinidos— están soportadas y se combinan con tiendas elegidas individualmente.

## Ejemplos

| Configuración | Lo que ve el empleado |
|---|---|
| Marca = "Marca Ejemplo" | Todas las tiendas y fuentes de esa marca |
| Tiendas = 1, 2, 3 | Todas las marcas que operan en esas tiendas |
| Marca = "Marca Ejemplo" + Tiendas = 1, 2 | Solo los datos de esa marca, en esas dos tiendas |
| Tiendas = 1 + Fuentes = Glovo, Uber | Solo datos de Glovo y Uber en la tienda 1, donde aplique el filtro de fuente |

## Nota sobre Fuentes

El filtro de fuentes es una dimensión complementaria con **activación limitada**. No todos los módulos lo usan: solo tiene efecto en secciones donde filtrar por origen del pedido tiene sentido. Entre ellas:

- **Informes** — datos de ventas solo de agregadores concretos
- **Métricas** — líneas temporales y logs de pedidos filtrados a ciertos canales
- **CMS** — configuración de contenido delimitada a fuentes específicas
- **Hub** — casos especiales en los que un operador solo gestiona pedidos de ciertos orígenes

En los módulos donde el filtro de fuentes no está activado, el empleado ve todos los pedidos dentro de su scope de marca y tienda, independientemente de esta configuración.

> Por eso Fuentes encaja mejor en roles especializados que necesitan una vista más estrecha dentro de una sección concreta, y no como restricción de uso general.

## Lo que el scope no hace

El scope nunca concede nada: solo reduce. Un empleado con el scope limitado a unas tiendas y sin ningún rol de informes sigue sin poder abrir los informes. El scope decide *qué datos*; los roles deciden *qué acciones*. Ver [Roles y scope: las dos ideas](/books/console/page/roles-y-scope-las-dos-ideas).

# Catálogo de roles

Cada rol cubre un área de responsabilidad. Si alguien necesita dos áreas, dale dos roles — ver [Combinaciones habituales de roles](/books/console/page/combinaciones-habituales-de-roles).

| Rol | Para quién | Qué cubre |
|---|---|---|
| `admin` | Administrador del cliente | Todo excepto gestionar las definiciones de roles. Es el rol más alto que se asigna a empleados del cliente |
| `hub_manager` | Jefe de operaciones | Hub completo —asignar, forzar entrega, cancelar, modificar ETA, incidencias, alarmas— más configuración de tienda, pausar reparto, métricas y alarmas archivadas |
| `hub_operator` | Operador de turno del hub | Operaciones básicas del hub, sin las acciones críticas. Ver tiendas y métricas |
| `branch_manager` | Responsable de tienda | Su propia tienda: ver pedidos, modificar ETA, incidencias, alarmas, alertas de repartidor, pausar reparto, configuración de tienda |
| `branch_viewer` | Acceso de solo lectura a tiendas | Solo consulta de la configuración de tiendas. Rol de apoyo, pensado para combinarse con otros |
| `dispatcher_manager` | Técnico de logística | Ejecución del dispatcher, planificador, configuración de tienda, pausar reparto, zonas de reparto, transportistas externos, métricas |
| `report_viewer` | Dirección y analistas | Informes, métricas, ver tiendas |
| `polygon_manager` | Configuración de zonas de reparto | Zonas de reparto, ver tiendas |
| `cms_editor` | Editor de contenidos | Árbol de reclamaciones, recursos, imágenes |
| `employee_manager` | RR. HH. y configuración de personal | Empleados y repartidores propios, además de asignaciones de roles, scope y excepciones |
| `third_party_manager` | Configuración de flota externa | Configuración de transportistas externos, a nivel de marca |
| `alarms_config_manager` | Configuración de umbrales de alarma | Umbrales de alarma de pedidos, repartidores y tiendas, para toda la cadena |

## Dos roles que no vas a asignar

**`super_admin`** es un rol técnico interno de PizzaGest. Tiene acceso total y se salta todas las comprobaciones; nunca se asigna a empleados del cliente.

**`admin`** es su equivalente del lado del cliente para el día a día: el mismo alcance operativo, salvo que los denies individuales le siguen aplicando y no puede modificar las definiciones de roles.

## Cómo se suman los permisos

Los roles se construyen a partir de un catálogo de permisos atómicos —actualmente más de cincuenta—, cada uno correspondiente a una acción concreta como "asignar un repartidor" o "exportar métricas".

Un rol es un subconjunto con nombre de ese catálogo. Cuando un empleado tiene varios roles, sus permisos se combinan sin duplicados. Añadir un rol nunca resta nada.

> El número de permisos por rol cambia según se publican módulos nuevos. En lugar de memorizar una cifra, consulta lo que concede realmente un rol en [Acceso por sección](/books/console/page/acceso-por-seccion), o abre el rol en la pantalla de Catálogo de roles.

## Módulos añadidos recientemente

La configuración del chatbot, la gestión de la API externa, el agente de voz, los códigos promocionales y los códigos de voucher son accesibles hoy únicamente para `admin`. Está pendiente decidir si tendrán un rol propio o se incorporan a los existentes, según la necesidad operativa.

Si alguno de ellos tiene que llegar antes a un empleado que no es `admin`, la vía prevista es una excepción individual — ver [Excepciones individuales de permisos](/books/console/page/excepciones-individuales-de-permisos).

# Acceso por sección

La rejilla completa de lo que alcanza cada rol. **Leyenda:** 👁 solo lectura · ✏️ lectura y escritura · — sin acceso.

Todo el acceso que se muestra aquí queda además filtrado por el scope del empleado — ver [Scope: qué datos puede ver un empleado](/books/console/page/scope-que-datos-puede-ver-un-empleado).

| Sección | admin | hub_manager | hub_operator | dispatcher_manager | branch_manager | report_viewer | polygon_manager | cms_editor | employee_manager | third_party_manager | alarms_config_manager |
|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
| Hub — pedidos y estado | ✏️ | ✏️ | ✏️ básico | — | 👁 | — | — | — | — | — | — |
| Hub — forzar entrega / cancelar | ✏️ | ✏️ | — | — | — | — | — | — | — | — | — |
| Hub — modificar ETA | ✏️ | ✏️ | — | — | ✏️ | — | — | — | — | — | — |
| Alarmas de tienda | ✏️ | ✏️ | 👁 | — | 👁 | — | — | — | — | — | — |
| Alertas de repartidor | ✏️ | 👁 | 👁 | — | 👁 | — | — | — | — | — | — |
| Configuración de umbrales de alarma | ✏️ | — | — | — | — | — | — | — | — | — | ✏️ |
| Alarmas archivadas | ✏️ | 👁 | — | — | — | — | — | — | — | — | — |
| Dispatcher | ✏️ | — | — | ✏️ | — | — | — | — | — | — | — |
| Planificador | ✏️ | — | — | ✏️ | — | — | — | — | — | — | — |
| Configuración de tienda | ✏️ | ✏️ | 👁 | ✏️ | ✏️ | 👁 | 👁 | — | — | — | — |
| Pausar / reanudar reparto | ✏️ | ✏️ | — | ✏️ | ✏️ | — | — | — | — | — | — |
| Transportistas externos — marca | ✏️ | — | — | ✏️ | — | — | — | — | — | ✏️ | — |
| Transportistas externos — tienda | ✏️ | — | — | ✏️ | — | — | — | — | — | — | — |
| Zonas de reparto | ✏️ | — | — | ✏️ | — | — | ✏️ | — | — | — | — |
| Métricas | ✏️ | 👁 | 👁 | 👁 | — | 👁 | — | — | — | — | — |
| Informes de ventas | ✏️ | — | — | — | — | 👁 | — | — | — | — | — |
| Empleados y repartidores propios | ✏️ | — | — | — | — | — | — | — | ✏️ | — | — |
| CMS — reclamaciones y recursos | ✏️ | — | — | — | — | — | — | ✏️ | — | — | — |
| Configuración del chatbot ¹ | ✏️ | — | — | — | — | — | — | — | — | — | — |
| Gestión de la API externa ¹ | ✏️ | — | — | — | — | — | — | — | — | — | — |
| Agente de voz ¹ | ✏️ | — | — | — | — | — | — | — | — | — | — |
| Códigos promocionales ¹ | ✏️ | — | — | — | — | — | — | — | — | — | — |
| Códigos de voucher ¹ | ✏️ | — | — | — | — | — | — | — | — | — | — |
| Gestión de roles y asignaciones | ✏️ | — | — | — | — | — | — | — | ✏️ | — | — |

¹ **Módulos añadidos recientemente**, accesibles hoy solo para `admin`. Ver [Catálogo de roles](/books/console/page/catalogo-de-roles).

## Cómo leer esta tabla

- `super_admin` tiene ✏️ en todas las filas; se omite para que la tabla siga siendo legible.
- `branch_viewer` es un rol de apoyo de solo lectura sobre la configuración de tiendas; se omite por el mismo motivo. Combínalo con otro rol en lugar de usarlo solo.
- "✏️ básico" en `hub_operator` significa las acciones habituales del hub, pero **no** las críticas: se excluyen forzar entrega, cancelar y modificar ETA.
- **Gestión de roles y asignaciones** se divide en dos: `employee_manager` puede asignar roles existentes, configurar el scope y gestionar excepciones, pero no puede crear ni editar definiciones de roles. Ver [Gestionar roles desde la consola](/books/console/page/gestionar-roles-desde-la-consola).

## Si un rol casi encaja

No busques un rol que coincida exactamente con una persona. O combinas dos roles ([Combinaciones habituales de roles](/books/console/page/combinaciones-habituales-de-roles)), o mantienes el rol más cercano y añades una sola excepción ([Excepciones individuales de permisos](/books/console/page/excepciones-individuales-de-permisos)).

# Combinaciones habituales de roles

Como un empleado puede tener varios roles y todos comparten un único scope, la mayoría de los perfiles reales se construyen combinando dos o tres roles en lugar de buscar una coincidencia perfecta.

| Perfil real | Roles | Scope |
|---|---|---|
| Jefe de operaciones que además consulta informes | `hub_manager` + `report_viewer` | Customer, o explícito por tiendas |
| Jefe de operaciones que gestiona umbrales de alarma | `hub_manager` + `alarms_config_manager` | Customer, o explícito por tiendas |
| Jefe de operaciones que además opera el dispatcher | `hub_manager` + `dispatcher_manager` | Customer, o explícito por tiendas |
| Operador de turno que además consulta informes | `hub_operator` + `report_viewer` | Explícito — sus tiendas |
| Responsable de tienda con acceso a informes | `branch_manager` + `report_viewer` | Explícito — sus tiendas |
| Responsable de marca que no opera pedidos | `employee_manager` + `polygon_manager` + `third_party_manager` | Explícito — marca |
| Técnico de zonas de reparto | `polygon_manager` | Explícito — marca |
| Dirección, solo datos | `report_viewer` | Customer |
| Administrador completo | `admin` | Customer |

## Por qué `hub_manager` no incluye el dispatcher

`hub_manager` se centra deliberadamente en las operaciones del hub. Si tu jefe de operaciones también necesita el dispatcher, el planificador o los transportistas externos, asígnale `hub_manager` + `dispatcher_manager`.

Cada rol mantiene su área de responsabilidad y los permisos se combinan automáticamente. Es preferible a ampliar `hub_manager`, porque deja las dos responsabilidades visibles y se pueden retirar por separado.

## Reglas prácticas

**Combina roles, no pidas roles nuevos.** La mayoría de necesidades son una combinación que ya existe. Una definición de rol nueva requiere una solicitud al equipo de desarrollo — ver [Solicitar un rol nuevo o modificado](/books/console/page/solicitar-un-rol-nuevo-o-modificado).

**Los roles solo suman.** Asignar un segundo rol nunca reduce lo que concedía el primero, ni amplía los datos visibles. Eso solo lo controla el scope.

**Usa excepciones para el caso puntual.** Si un perfil coincide con un rol existente salvo por una única capacidad, mantén el rol y añade un grant o un deny individual — ver [Excepciones individuales de permisos](/books/console/page/excepciones-individuales-de-permisos).

# Cómo funciona el scope en la práctica

Cuatro comportamientos explican casi todas las preguntas del tipo "¿por qué esta persona ve eso?".

## Los roles se suman

Un empleado con `hub_manager` + `report_viewer` puede operar el hub **y** consultar informes. Ninguno de los dos roles restringe al otro, y el orden en que los asignes da igual.

## El scope filtra los datos automáticamente

Tener acceso a un módulo no significa ver todos sus datos. El sistema filtra todo al scope del empleado.

Un `report_viewer` cuyo scope está limitado a la marca "Pizza Express" abre la misma pantalla de informes que los demás, pero solo ve las cifras de esa marca. No hay nada oculto ni en gris: simplemente esos datos no están en sus resultados.

> Conviene explicarlo directamente a las personas. Que dos compañeros comparen el mismo informe y vean totales distintos es el comportamiento esperado, no un fallo.

## El scope se aplica igual a todos los roles

A diferencia de sistemas antiguos, el scope **no** se configura por rol. Si un empleado puede ver las tiendas 1, 2 y 3, eso aplica a todo lo que haga: hub, informes, métricas, configuración de tienda, todo.

Es una simplificación deliberada: permite razonar sobre la visibilidad de un empleado mirando una sola configuración, en lugar de reconciliar varias.

## Las excepciones individuales mandan sobre los roles

Puedes conceder o denegar un permiso concreto a un empleado concreto, opcionalmente con fecha de caducidad.

**Un deny siempre gana**, conceda lo que conceda su rol. Ver [Excepciones individuales de permisos](/books/console/page/excepciones-individuales-de-permisos).

## Cómo encajarlo todo

Cuando alguien reporta que no puede hacer algo, comprueba en este orden:

1. **¿Tiene un rol que conceda esa acción?** → [Acceso por sección](/books/console/page/acceso-por-seccion)
2. **¿Hay un deny sobre esa persona?** → [Excepciones individuales de permisos](/books/console/page/excepciones-individuales-de-permisos)
3. **¿Los datos están simplemente fuera de su scope?** → [Configurar el scope de un empleado](/books/console/page/configurar-el-scope-de-un-empleado)

La mayoría de los casos se resuelven en el paso 3, y hasta que lo compruebas parecen un permiso que falta.

# Gestionar roles desde la consola

La consola gestiona roles, asignaciones, scopes y excepciones individuales a través de cuatro secciones.

| Sección | Qué permite | Permisos necesarios |
|---|---|---|
| [Catálogo de roles](/books/console/page/catalogo-de-roles) | Ver, crear, editar y eliminar definiciones de roles: su nombre y los permisos que incluyen | `roles:read` / `roles:write` |
| **Asignaciones** | Asignar y desasignar roles a empleados, activarlos y desactivarlos | `employees:read` / `employees:write` |
| **Scope** | Configurar a qué datos accede cada empleado: marcas, tiendas, fuentes | `employees:read` / `employees:write` |
| **Excepciones** | Crear grants o denies individuales sobre un permiso concreto de un empleado, con fecha de caducidad opcional | `employees:read` / `employees:write` |

## Quién llega a cada sección

[Catálogo de roles](/books/console/page/catalogo-de-roles) está restringido a `super_admin`, el rol técnico propio de PizzaGest. Crear o cambiar una definición de rol pasa por el equipo de desarrollo, que revisa el cambio antes de aplicarlo. Ver [Solicitar un rol nuevo o modificado](/books/console/page/solicitar-un-rol-nuevo-o-modificado).

**Asignaciones, Scope y Excepciones** están disponibles para `admin` y `employee_manager`. Son las tres que usarás en el día a día: asignar roles existentes, configurar el scope y gestionar excepciones.

> La separación es deliberada. Cambiar lo que *significa* un rol afecta a todos los empleados que lo tienen, en toda la cadena, así que se revisa. Cambiar *quién* tiene un rol afecta a una persona y lo haces tú directamente.

## Asignar un rol a un empleado

1. Abre **Asignaciones**.
2. Busca al empleado.
3. Añade el rol o los roles que necesita — ver [Catálogo de roles](/books/console/page/catalogo-de-roles) y [Combinaciones habituales de roles](/books/console/page/combinaciones-habituales-de-roles).
4. Confirma su scope aparte, en **Scope**. Un rol nuevo no cambia el scope existente.

Una asignación se puede desactivar en lugar de eliminar, lo que conserva el registro y suspende el acceso.

> Asignar un rol no le da a nadie forma de entrar. Establecer o restablecer su contraseña es una tarea aparte, desde la pantalla de Empleados — ver [Empleados - Contraseña](/books/console/page/empleados-contrasena).

## Salvaguardas

Protegen frente a los cambios más difíciles de deshacer:

- Un rol con asignaciones activas **no se puede eliminar**.
- Los permisos asociados a un rol se validan contra el catálogo de permisos del sistema, de modo que una errata no puede crear un permiso que no haga nada.
- Cada asignación y cada excepción registra **quién la creó**, para auditoría.
- Los denies individuales siempre prevalecen sobre lo que concede un rol.

## Páginas relacionadas

- [Configurar el scope de un empleado](/books/console/page/configurar-el-scope-de-un-empleado) — las tres dimensiones en la práctica
- [Excepciones individuales de permisos](/books/console/page/excepciones-individuales-de-permisos) — grants y denies
- [Solicitar un rol nuevo o modificado](/books/console/page/solicitar-un-rol-nuevo-o-modificado) — cuando ninguna combinación encaja

# Configurar el scope de un empleado

> **Necesitas:** `employees:read` y `employees:write` — los tienen `admin` y `employee_manager`.

El scope se configura una vez por empleado y aplica a todo lo que hace. Ver [Scope: qué datos puede ver un empleado](/books/console/page/scope-que-datos-puede-ver-un-empleado) para el modelo; esta página es la tarea.

## Antes de empezar

Decide cuál de los dos modos necesita la persona:

- **Customer** — necesita legítimamente toda la cadena. Dirección, analistas, operaciones a nivel de cadena.
- **Explicit** — todos los demás. Cualquiera vinculado a tiendas concretas o a una marca concreta.

En caso de duda, elige explícito y amplía después. Ampliar un scope más adelante es cambiar un campo; descubrir que alguien lleva meses viendo las cifras de otra marca, no.

## Configurar un scope explícito

1. Abre **Scope** y busca al empleado.
2. Cambia el modo a **Explicit**.
3. Rellena solo las dimensiones que realmente quieras restringir:
   - **Marcas** — déjalo vacío para "todas las marcas".
   - **Tiendas** — tiendas individuales, agrupaciones, o ambas.
   - **Fuentes** — solo si la restricción importa de verdad; ver la advertencia más abajo.
4. Guarda y comprueba el resultado en una pantalla que use el empleado, por ejemplo Informes.

> Dejar una dimensión vacía significa **sin restricción en esa dimensión**, no "sin acceso". Un scope explícito con todas las dimensiones vacías equivale a acceso total.

## Usar agrupaciones de tiendas

Las agrupaciones son conjuntos predefinidos de tiendas. Se combinan con las tiendas seleccionadas individualmente en lugar de sustituirlas, así que puedes dar a alguien una región más una tienda suelta sin enumerar la región tienda por tienda.

Es preferible una agrupación a una lista larga de tiendas: cuando más adelante se añada una tienda a esa región, el scope del empleado la recoge automáticamente.

## Advertencia sobre Fuentes

El filtro de fuentes solo surte efecto en los módulos que lo implementan: Informes, Métricas, CMS y algunos casos del Hub. En el resto, el empleado ve todo lo que hay dentro de su scope de marca y tienda.

Esto significa que una restricción por fuente **no** es una forma fiable de ocultar datos en general. Úsala para enfocar un rol especializado, no para imponer un límite. Si el límite importa, exprésalo con marcas o tiendas.

## Comprobar el resultado

La verificación más rápida es mirar una pantalla con volumen de datos, como Informes o la lista de pedidos del hub, y confirmar que el empleado ve lo que pretendías: ni más, ni menos.

Recuerda que el scope no concede nada. Si no ve absolutamente nada, revisa sus roles antes de tocar el scope — ver [Cómo funciona el scope en la práctica](/books/console/page/como-funciona-el-scope-en-la-practica).

# Excepciones individuales de permisos

> **Necesitas:** `employees:read` y `employees:write` — los tienen `admin` y `employee_manager`.

Una excepción concede o deniega un permiso concreto a un empleado concreto, por encima de lo que digan sus roles. Úsala cuando una persona encaja con un rol existente en todo salvo en un detalle.

## Los dos tipos

| Tipo | Efecto | Uso típico |
|---|---|---|
| **Grant** | Añade un permiso que sus roles no incluyen | Un operador de turno que además necesita cancelar pedidos, sin darle el rol de jefe entero |
| **Deny** | Retira un permiso que sus roles sí incluyen | Un responsable de tienda que no debería poder pausar el reparto |

## La regla que resuelve los conflictos

**Un deny siempre gana.** Prevalece sobre cualquier grant, venga del rol que venga, e incluso sobre un grant explícito. No hay orden que razonar ni prioridad que configurar.

Es deliberado: hace que un deny sea una forma fiable de retirar una capacidad, sin tener que auditar qué roles podrían estar devolviéndola.

> `super_admin` es la única excepción: se salta todas las comprobaciones, incluidos los denies. `admin` **no**; a `admin` los denies individuales le aplican con normalidad.

## Crear una

1. Abre **Excepciones** y busca al empleado.
2. Elige el permiso.
3. Elige grant o deny.
4. Opcionalmente, pon una fecha de caducidad.
5. Guarda. El registro conserva quién la creó, para auditoría.

## Usa la fecha de caducidad

La mayoría de las excepciones nacen con intención temporal: cubrir una ausencia, una campaña de temporada, una prueba de acceso más amplio. Muy pocas acaban siendo temporales en la práctica, porque nadie se acuerda de retirarlas.

Poner la fecha de caducidad al crearla convierte ese problema en un no-problema. Si el acceso resulta ser permanente, la solución correcta es cambiar el rol, no una excepción que no termina nunca.

## Cuándo no usar una excepción

**Cuando dos roles ya lo cubren.** Si la persona necesita un área completa, asigna el rol de esa área — ver [Combinaciones habituales de roles](/books/console/page/combinaciones-habituales-de-roles). Las excepciones son para permisos sueltos, no para montar un área a base de piezas.

**Cuando varias personas necesitan lo mismo.** Tres excepciones idénticas son señal de que el rol está mal planteado. Solicita un cambio de rol — ver [Solicitar un rol nuevo o modificado](/books/console/page/solicitar-un-rol-nuevo-o-modificado).

**Para restringir datos.** Las excepciones controlan acciones, no visibilidad. Para limitar lo que alguien ve, configura su scope — ver [Configurar el scope de un empleado](/books/console/page/configurar-el-scope-de-un-empleado).

## Revisarlas

Las excepciones son la parte del modelo de acceso que más se desvía con el tiempo, porque cada una es invisible desde el catálogo de roles. Revisa la lista periódicamente y retira las que ya no tengan motivo.

# Solicitar un rol nuevo o modificado

Crear o editar una definición de rol está restringido al equipo técnico de PizzaGest. Como administrador del cliente asignas roles existentes, configuras el scope y gestionas excepciones, pero el catálogo de roles en sí pasa por una solicitud.

Esta página explica por qué, y cómo plantear bien esa solicitud.

## Por qué se revisa

Una definición de rol es compartida. Cambiar lo que significa `hub_manager` lo cambia para todos los empleados que lo tienen, en todas las tiendas, de inmediato. A diferencia de una asignación —que afecta a una persona y es fácil de revertir—, un cambio de rol tiene alcance de cadena, así que se revisa antes de aplicarse.

## Prueba esto primero

La mayoría de las solicitudes acaban siendo innecesarias. Por orden de preferencia:

1. **Combina roles existentes.** Dos o tres roles juntos cubren casi todos los perfiles reales — ver [Combinaciones habituales de roles](/books/console/page/combinaciones-habituales-de-roles).
2. **Añade una excepción individual.** Si un rol encaja salvo por una capacidad, concede o deniega ese permiso — ver [Excepciones individuales de permisos](/books/console/page/excepciones-individuales-de-permisos).
3. **Comprueba que no sea un problema de scope.** "No ve los datos" casi siempre es scope, no permisos — ver [Cómo funciona el scope en la práctica](/books/console/page/como-funciona-el-scope-en-la-practica).

Un rol nuevo es la respuesta correcta cuando el mismo patrón de combinación más excepción se repite en varias personas.

## Qué incluir en la solicitud

| Dato | Por qué importa |
|---|---|
| El puesto, en lenguaje llano | "Supervisor regional de 12 tiendas" dice más que una lista de permisos |
| Qué debe poder hacer | Las acciones, nombradas como aparecen en la consola |
| Qué **no** debe poder hacer | A menudo es la mitad más importante, y la que suele faltar |
| El rol existente más cercano | Y en qué se queda corto exactamente |
| Cuántas personas lo tendrán | Una persona suele ser una excepción; varias suelen ser un rol |
| Si es permanente | Una necesidad de temporada se cubre mejor con excepciones con caducidad |

## Qué ocurre después

La solicitud se analiza frente al catálogo existente, en parte para construir el rol adecuado y en parte para comprobar que no se solapa con otro de una forma que complique razonar sobre el modelo.

Si se crea un rol nuevo, aparece en el Catálogo de roles y lo asignas como cualquier otro.

## Mientras tanto

No hace falta dejar a nadie bloqueado. Asigna el rol más cercano y cubre la diferencia con excepciones, idealmente con una fecha de caducidad acorde a tu plazo previsto. Cuando llegue el rol nuevo, asígnalo y retira las excepciones.