Base de conocimiento
Roles y niveles de permiso
Un rol dice qué puede hacer alguien; una concesión de dirección dice sobre qué puede hacerlo.
Detalles
- Dos concesiones por persona, y ambas tienen que coincidir antes de que ocurra nada. El ROL, definido en Settings → Members, dice qué puede HACER en el espacio de trabajo: leer correo, enviarlo, editar plantillas, añadir un dominio, acuñar una clave de API. La CONCESIÓN de dirección, definida desde el control Share de la fila de la dirección, dice sobre qué DIRECCIONES puede hacerlo, en solo lectura o en lectura y envío. Quien tiene un rol con envío y ninguna dirección no puede enviar desde nada; quien tiene todas las direcciones del espacio de trabajo con una concesión de solo lectura tampoco puede enviar desde ninguna.
- Existen seis roles sin que nadie los cree, y todos los espacios de trabajo tienen los mismos seis, así que «Admin» significa aquí lo mismo que en la documentación y en la API. Owner, Admin, Member y Viewer son una escalera: cada uno contiene todo lo del siguiente, así que degradar a alguien estrecha lo que puede alcanzar en lugar de cambiárselo por otra porción distinta. Developer y Billing no son peldaños de esa escalera. Developer construye integraciones, con claves de API, webhooks, plantillas y envío, sin leer nada del correo del espacio de trabajo, y Billing ve el plan y las facturas, puede cambiar el plan y los datos de pago, y lee los ajustes del buzón sin poder escribir ninguno. Sus permisos son editables: un espacio de trabajo que prefiera que sus miembros no escriban plantillas lo desmarca, y el cambio llega en la siguiente petición que haga cualquiera que tenga ese rol EXPLÍCITAMENTE. Quien tiene un rol todavía implícito por una concesión de dirección hecha antes de que existieran los roles conserva los valores de fábrica hasta que se le asigne uno de forma expresa. Sus nombres también lo son: un espacio de trabajo que funciona con Ops y On-call los renombra y se está describiendo a sí mismo, que es de lo que se trata.
- Owner es la excepción en todas las direcciones: no editable, no eliminable, no asignable. Describe la cuenta sobre la que está anclado el espacio de trabajo y tiene todos los permisos, incluidos los añadidos en una versión posterior, y por eso su lista se calcula en lugar de almacenarse. Entregar el espacio de trabajo a otra persona es una transferencia y no un cambio de rol, y aquí no hay nada que haga una.
- Más allá de esos, un espacio de trabajo escribe los suyos, hasta 24 en total, marcando permisos en la misma matriz agrupada. Marcar implica: «edit templates» guarda «read templates» junto a él, porque un rol que puede editar una plantilla que no puede abrir es una casilla que alguien olvidó y no una política que nadie pretenda. Eliminar un rol que tienen personas o claves de API pregunta a dónde moverlas y se niega en lugar de adivinar. Una clave cuyo rol desapareciera quedaría sin ningún techo, lo cual es más amplio que el rol que acaba de irse.
- Una clave de API se puede emitir contra un rol, y el rol es un techo y no una segunda concesión: lo que la clave puede hacer son sus propios ámbitos intersecados con los permisos del rol, resueltos en cada petición. Una clave creada con envío y limitada por Viewer no puede enviar, y estrechar un rol lo revoca en vivo sin que haya que rotar la clave. El asistente está sujeto a la misma lista, y el servidor MCP construye las herramientas de un cliente a partir de los permisos de quien llama, así que el cliente de un viewer no tiene ninguna herramienta de envío, y cada herramienta protegida vuelve a comprobar al entrar porque una sesión puede cambiar de buzón después de construirse la lista.