Acceso e identidad

Los usuarios y los espacios de trabajo son cuentas y pueden poseer Playbooks. Playbooks y Casos usan access: { visibility, grants }. La visibilidad es restricted o public; los permisos guardados en grants asignan UUID de cuentas de usuario o equipos a viewer o editor. public nunca es una clave de permisos. Las actualizaciones reemplazan toda la configuración atómicamente: conserve los permisos existentes al cambiar solo la visibilidad. La creación conserva la edición del creador mediante un permiso directo o un permiso de edición de un Equipo seleccionado. Las actualizaciones deben conservar al menos un usuario o equipo editor explícito, independientemente de la propiedad o publicación.

Elegir el acceso inicial

Al crear un Caso o Playbook, o copiar un Playbook en un Espacio de trabajo, elija exactamente una opción, incluso si el Espacio procede del valor predeterminado de la credencial o conexión:

En el espacio personal puede omitirse la configuración. Un miembro sin derechos de administración puede crear o copiar un Playbook con acceso restringido al creador o edición para sus Equipos actuales del Espacio; otros permisos iniciales requieren un propietario o administrador.

Las claves de access.grants aceptan UUID de usuarios o Equipos, o correos de usuarios registrados. Los correos se resuelven a UUID antes de guardar; las respuestas siempre usan UUID. Un correo y un UUID del mismo usuario con el mismo rol se agrupan. Un correo no registrado o roles en conflicto para el mismo usuario resuelto rechazan toda la operación.

Los cambios de acceso requieren el objeto access completo. Lea primero la configuración actual, conserve los permisos ajenos al cambio y mantenga al menos un editor. No se añade un Equipo ni se elimina el acceso propio automáticamente; incluya u omita explícitamente su permiso directo.

Propiedad y acceso continuo

Los lectores pueden leer contenido compartido, pero no editar; los borradores requieren edición. Los editores pueden cambiar contenido y permisos, conservar al menos un editor explícito al cambiar permisos, archivar y restaurar. Transferir la cuenta propietaria, cambiar el mantenedor, eliminar Casos definitivamente y archivar versiones históricas requieren derechos de propietario. assignedTo indica responsabilidad sin conceder acceso. Un nuevo responsable o mantenedor debe tener edición y, en recursos del Espacio, pertenecer a ese Espacio. Reasignar conserva los permisos; transferir la propiedad no añade automáticamente al antiguo propietario como editor.

Playbooks y Casos tienen una cuenta propietaria de Usuario o Espacio de trabajo (ownerId), que también paga su uso. El propietario personal tiene todos los derechos; los Owners y Admins actuales ejercen esos derechos para un Espacio de trabajo. Los demás miembros necesitan permisos explícitos de usuario o Equipo, o visibilidad pública para leer contenido publicado. La membresía por sí sola no concede acceso. Al eliminar un miembro, se revocan sus permisos directos sobre los recursos propiedad de ese Espacio, incluidos los completados y archivados. Si la eliminación dejara algún recurso sin editor explícito, añada primero otro usuario o equipo editor, incluidos los recursos completados o archivados. Se conservan los permisos sobre recursos personales y de otros Espacios. Los permisos de Equipo y administración dependen de la membresía actual. El SSO obligatorio se aplica a los miembros; los usuarios externos con permisos directos usan la autenticación normal de Epismo. El acceso de Equipo entre espacios verifica el SSO del espacio de participación. Los listados usan permisos explícitos y la visibilidad pública admitida; la propiedad por sí sola no incluye un recurso.

Omita ownerId al crear o copiar para usar el Espacio de trabajo activo, o su cuenta personal si no hay uno seleccionado. La selección explícita también requiere autorización. Mantener o tener asignado un recurso no sustituye los permisos.

Los Casos públicos muestran el título, entrada, Tareas, Registros y traspasos legibles actuales, incluidas las incorporaciones posteriores. Incluyen referencias públicas de las cuentas de autores y responsables, pero omiten los permisos privados, fuentes vinculadas, informes y resúmenes de Review y configuración privada. La web muestra identificadores públicos y avatares; las personas sin identificador público aparecen como usuario anónimo sin avatar. La publicación nunca permite editar o cambiar la asignación. Los Playbooks públicos tampoco exponen borradores.

Los permisos de Caso y Playbook son independientes. Iniciar desde un Playbook legible no copia sus permisos al Caso. Seleccione el acceso del Caso según sus entradas y evidencia. Cambiar los permisos del Caso oculta los informes de Review generados para la audiencia anterior. Una nueva evaluación utiliza la evidencia disponible para la audiencia actual del Caso.

Un equipo puede conectar varios espacios de trabajo. Su permiso se aplica solo mientras el espacio de participación del usuario y el origen del recurso sigan conectados. Desconectar elimina los participantes de ese espacio y retira inmediatamente su acceso mediante el equipo; las otras conexiones y los permisos directos a usuarios permanecen. Reconectar restaura el acceso mediante los permisos conservados.

La autorización usa propiedad, permisos, membresía y SSO actuales. Los filtros de Registros solo acotan resultados autorizados; nunca conceden acceso. Los editores pueden consultar todos los permisos con access-get. capabilities.canManage y capabilities.canEdit describen las capacidades de la solicitud actual; el cliente no puede enviarlos como permisos. Repetir una actualización de permisos devuelve su respuesta original guardada.

Las Sugerencias pertenecen al Playbook padre actual y no tienen propietario ni permisos históricos independientes. authorId identifica al creador y baseVersionId conserva la referencia de contenido inmutable para evaluar la mejora. La lectura requiere acceso actual al padre; archivarlo oculta sus Sugerencias hasta restaurarlo. Los autores pueden editar sus propuestas abiertas mientras mantengan acceso; los editores actuales del Playbook pueden adoptar o rechazar propuestas. Tras una transferencia, las propuestas existentes siguen los permisos actuales del padre. Publique el resultado antes de marcar la propuesta como aplicada.

Los alias proporcionan nombres y las URL compartidas redirigen al recurso sujeto a sus permisos actuales. No conceden acceso ni cambian la propiedad. Use un UUID de idempotencia para cada mutación; reutilícelo solo al repetir una solicitud idéntica con respuesta incierta. Las actualizaciones de Casos y Tareas existentes también requieren la última versión de bloqueo.

El encabezado de Equipos visibles selecciona o deselecciona todos los Equipos a la vez. La barra lateral web limita los resultados a los permisos directos del Usuario y los Equipos seleccionados, incluidos los recursos de otras cuentas propietarias compartidos mediante Equipos conectados. Se pueden deseleccionar todos los Equipos; la selección vacía se conserva y mantiene los permisos directos del Usuario. Los listados del Espacio, búsquedas, archivos y bandejas no filtran implícitamente por propietario. La selección no cambia el acceso mediante enlaces directos, las capacidades de edición ni los permisos de modificación. API, CLI y MCP usan la visibilidad normal según el acceso y no ofrecen el filtro de Equipos de la barra lateral.

Alcance de uso compartido y descubrimiento

La visibilidad usa restricted o public. El filtro independiente sharingScope acepta private, shared o anyone: Private corresponde a un único Usuario conocido; Shared incluye varios Usuarios o cualquier Equipo, Espacio de trabajo o destinatario sin resolver; Anyone corresponde a visibilidad pública. La clasificación incluye al propietario del Playbook o responsable del Caso y no depende del lector. La visibilidad restringida admite permisos explícitos de Usuario o Equipo.

Omitir sharingScope incluye todas las clasificaciones dentro del alcance verificado. Los filtros solo reducen los resultados legibles; nunca conceden acceso. Las listas de Casos y Playbooks, la búsqueda de Playbooks y los agregados de recursos admiten este filtro. En CLI use --sharing-scope; el mantenedor de Playbooks se filtra con --assigned-to. Se eliminaron includePublic y --include-public.

Descubra Casos con GET /v1/cases, epismo_case_list o epismo case list, por actualización e ID descendentes. Las solicitudes anónimas reciben Casos públicos, incluso sin Registros. playbookId (--playbook-id) selecciona el Playbook de origen y se combina con estado y alcance de uso compartido. assignedTo=me requiere autenticación. Se eliminó el descubrimiento por popularidad. Las listas archivadas siguen requiriendo acceso privado.

Las listas operativas Web excluyen los recursos accesibles solo por publicación; Explorar usa autoridad pública incluso con sesión iniciada. API, CLI y MCP incluyen recursos públicos de forma predeterminada.