Acceso e identidad

Los usuarios y los espacios de trabajo son cuentas y pueden poseer Playbooks. Un Playbook expone visibility (private o public) y editors explícitos (ID de Cuenta de usuario o Equipo activos). public concede solo lectura del contenido publicado; los editores pueden leer y editar contenido. El propietario es implícito, nunca aparece como editor y siempre puede leer, editar, gestionar el acceso y archivar. En un Playbook propiedad de un Workspace, sus Owners y Admins son administradores propietarios con los mismos derechos. Los casos no admiten acceso público.

Las ACL de Playbook y Caso son independientes. Comenzar desde un Playbook público, compartido o legible por el equipo no copia su visibilidad en el Caso. Elija una ACL de caso explícitamente porque sus entradas, resultados y registros pueden ser más sensibles que la guía reutilizable.

La autorización se evalúa con respecto a las ACL actuales. Las lecturas de registros siempre intersectan los filtros con la ACL del caso en vivo; un filtro acl solo limita los resultados autorizados y nunca otorga acceso. El acceso a sugerencias también vuelve a verificar el Playbook de destino actual en lugar de depender únicamente de la instantánea del momento de la creación.

Solo un administrador propietario puede gestionar el acceso, archivar el Playbook o archivar una Versión histórica. La última Versión no se puede archivar. Un usuario con lectura puede crear una Sugerencia; su autor puede editar una propuesta abierta, mientras el propietario del Playbook la resuelve. Los alias proporcionan nombres, los tokens compartidos proporcionan lecturas basadas en tokens y las estrellas proporcionan guardado personal; ninguno cambia de propietario.

Utilice UUID de idempotencia para mutaciones. Reutilice uno solo para la solicitud idéntica después de una respuesta incierta. Las mutaciones de casos y tareas también requieren versiones de bloqueo para que los colaboradores simultáneos no se sobrescriban silenciosamente entre sí.