Acceso e identidad

Los usuarios y los espacios de trabajo son cuentas y pueden poseer playbooks. Los casos y los playbooks usan visibility (private o public). public es un centinela de ACL de solo lectura: concede acceso solo al contenido publicado, nunca al trabajo no publicado, y nunca a editar o administrar.

En un caso, el contenido publicado es el título público, la entrada, los registros y el vecindario de traspaso legible. Las tareas, la asignación y las identidades de los colaboradores permanecen en la ACL de trabajo. Quienes están en esa ACL siguen leyendo el caso en vivo y, mientras está abierto, pueden editar el trabajo: tareas, asignación, título, cierre, reapertura, transferencias, añadir registros, solicitar una revisión de Epismo AI y si los registros OUTPUT encolan una. Los lectores públicos pueden obtener un caso público sin iniciar sesión. El responsable actual elige public/private y puede archivar el caso; started_by es historia y conserva acceso tras una reasignación solo si sigue en la ACL como editor.

En un playbook, el contenido publicado es la última versión. Los borradores siguen el acceso de edición. Los editores (ID de cuenta de usuario o equipo activos) 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, todos los miembros pueden leerlo y editarlo y también se omiten de la lista de editores; sus Owners y Admins son administradores propietarios y además gestionan el acceso, la visibilidad pública y el archivado.

Las ACL de caso y playbook 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. Hacer público un caso es un paso explícito y aparte.

Reasignar un caso conserva el acceso de edición del responsable anterior: si ningún permiso restante lo cubre, el servicio añade su ID de cuenta de usuario a la lista de editores. Del mismo modo, transferir un playbook de propiedad personal conserva el acceso de edición del anterior propietario (usuario). Un espacio de trabajo que deja de ser propietario no se añade automáticamente como editor. Cambiar la responsabilidad o la propiedad no revoca por sí solo el acceso del usuario anterior; revise la lista de editores por separado si desea retirarlo.

El responsable actual del caso tiene acceso implícito al trabajo y a la gestión y se omite de la lista de editores guardada. Una lista de editores vacía es válida. Los cambios de acceso deben conservar el acceso de cada responsable de tarea mediante editores explícitos, Equipos o ese permiso implícito.

La autorización se evalúa con respecto a las ACL actuales. Las lecturas de registros del caso en vivo siempre intersectan los filtros con la ACL del caso en vivo; un filtro acl solo limita los resultados autorizados y nunca otorga acceso. Los lectores públicos reciben la proyección publicada, no tareas ni identidades de colaboradores. 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 y los tokens compartidos proporcionan lecturas basadas en tokens; 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í.