No se pueden crear/editar flujos de trabajo

Preguntas
, , ,
1

Describe the problem/error/question

Como el propietario (y único) usuario en mi instancia de n8n autohospedada, no puedo editar ni crear NINGÚN flujo de trabajo — no puedo renombrar flujos de trabajo, no puedo mover/agregar/editar nodos, no puedo guardar cambios en el editor. Al pasar el cursor sobre el botón de alternar habilitar/deshabilitar para acceso MCP en Configuración se muestra «Solo los administradores de instancia pueden cambiar esto», a pesar de estar conectado como Propietario. Abrir MCP Settings > OAuth clients lanza «Error fetching list of OAuth clients».

Esto es a nivel de instancia — cada flujo de trabajo se ve afectado de manera idéntica, no solo uno. Ha persistido a través de una ruta completa de degradación/reimplementación de versión (2.39.0 → 2.38.1 → 2.37.10 → 2.36.7) y volviendo hasta 2.39.1 (actual), por lo que no está vinculado a una versión específica. Cerrar sesión e iniciar sesión nuevamente no ayudó. Solo hay un usuario en esta instancia (autohospedada, cuenta de Propietario único) — no hay otro usuario del cual «compartir» el flujo de trabajo o reasignar la propiedad.

Consulté directamente la base de datos de Postgres subyacente para descartar corrupción de datos como causa: la tabla role_scope otorga correctamente workflow:create, workflow:update, workflow:move, workflow:publish, mcp:manage, mcp:oauth, etc. a ambos roles global:owner y project:personalOwner, y mi fila de usuario está correctamente asignada a ambos a través de project_relation. Por lo tanto, los datos de permisos subyacentes son correctos en la DB — esto se ve como un error de resolución de alcance de backend específico de la autenticación basada en navegador/sesión. Como evidencia de apoyo: una clave API configurada con los mismos alcances subyacentes funciona completamente correctamente para las mismas acciones (crear/actualizar/mover nodos de flujo de trabajo) a través de la API — solo la sesión de navegador conectada está bloqueada.

Intentado: degradación de versión completa e reimplementación (múltiples versiones, sin cambios), cierre de sesión/inicio de sesión (sin cambios). Aún no he intentado una limpieza de datos de sitio duro (cookies/almacenamiento local) en el navegador, en caso de que un token de sesión obsoleto sea la causa en lugar de los datos de alcance en sí — actualizaré este hilo si eso cambia algo.

What is the error message (if any)?

En el editor: el flujo de trabajo es de solo lectura — no puedo renombrar, no puedo mover nodos, no puedo guardar.
En Settings > MCP: «Error fetching list of OAuth clients»
Al pasar el cursor sobre el botón de alternar habilitar/deshabilitar de MCP: «Solo los administradores de instancia pueden cambiar esto»

Please share your workflow

No específico del flujo de trabajo — ocurre de manera idéntica en cada flujo de trabajo en la instancia (15 total), por lo que ninguna exportación de flujo de trabajo único probablemente ayude aquí. Al parecer, todos los flujos de trabajo están configurados como «Read-Only»

image
image1798×912 62 KB

Share the output returned by the last node

N/A — this is an editor/permissions issue, not a node-execution issue.

Information on your n8n setup

  • n8n version: 2.39.1 (also reproduced on 2.39.0, 2.38.1, 2.37.10, 2.36.7)
  • Database (default: SQLite): PostgreSQL 16
  • n8n EXECUTIONS_PROCESS setting (default: own, main): queue mode (1 main + 2 workers), concurrency -1
  • Running n8n via (Docker, npm, n8n cloud, desktop app): Docker (self-hosted), managed via Portainer
  • Operating system: Linux (Ubuntu, VPS)
2

Hola @itsmhashim, mientras esperas una respuesta, aquí hay algunas cosas que podrían ayudarte:

Recursos sugeridos

Coincidencia automática con tu pregunta.

Documentación:

Foro:

@JohnBee, @Darien_Kindlund - ya han ayudado con problemas similares antes, ¿pueden echar un vistazo?

Sugerido automáticamente por el bot de la comunidad de n8n. Es un piloto - comparte tus comentarios aquí.

3

Hola @itsmhashim bienvenido a la comunidad de n8n.

Lienzo de solo lectura y la información sobre herramientas de MCP se controlan según los alcances que lleva tu sesión, no según las filas de rol que consultaste. Imprime esos primero.

const h = { 'browser-id': localStorage.getItem('n8n-browserId') };

console.log((await (await fetch('/rest/login', { headers: h })).json()).data.globalScopes);

Si viene vacío, es el problema de la sesión, no de tus datos.

También vale la pena descartar Issues · n8n-io/n8n · GitHub un contenedor Postgres huérfano compartiendo el alias de red, así que n8n leyó una base de datos obsoleta mientras psql leyó la actual.

4

Gracias por volver a ponerse en contacto conmigo. Ejecuté ambas verificaciones — aquí está lo que encontré:

  1. Prueba de ámbitos de sesión:
    total: 161
    workflow:update false
    workflow:create true
    workflow:move true
    mcp:manage true

Confirmé que mi sesión le falta exactamente workflow:update, mientras que los ámbitos hermanos (workflow:create, workflow:move) y mcp:manage están todos presentes. Verifiqué independientemente mediante una consulta directa a Postgres que role_scope otorga correctamente workflow:update a global:owner y project:personalOwner para mi usuario — así que la BD tiene la autorización, pero lo que sea que construye el array globalScopes de la sesión está eliminando workflow:update específicamente.

  1. Teoría del contenedor Postgres huérfano (#36249): descartada. Solo hay un contenedor Postgres ejecutándose (pgvector/pgvector:pg16, saludable), en la misma red Docker que n8n-main/worker-1/worker-2. Sin BD duplicada/obsoleta — n8n y mi consulta SQL directa están leyendo la misma base de datos activa.

  2. También confirmé que esto no se limita a flujos de trabajo existentes — un flujo de trabajo completamente nuevo en blanco (“My workflow”) también se representa completamente como solo lectura: el patrón de rayado diagonal que n8n usa para indicar un lienzo de solo lectura, barra de herramientas deshabilitada, no puedo agregar ningún nodo, botón Publicar deshabilitado. Esto coincide perfectamente con workflow:update siendo el único ámbito faltante — n8n parece cerrar la capacidad de edición de todo el lienzo en workflow:update, no solo en la acción API literal “update”, así que un workflow:update faltante hace que cada flujo de trabajo (nuevo o existente) sea permanentemente de solo lectura independientemente de que workflow:create esté presente.

    image
    image1849×916 53.4 KB

Así que esto se reduce a: workflow:update se otorga correctamente en role_scope, pero algo en lo que sea que calcule/fusione los globalScopes de la sesión está eliminándolo específicamente — y la verificación de lienzo de solo lectura del frontend se basa en ese mismo ámbito faltante, que es por qué nada (flujo de trabajo nuevo o antiguo) puede editarse en absoluto.

5

Ese 161 es la respuesta, y apunta directamente a la base de datos.

globalScopes no se calcula ni se fusiona de nada. getGlobalScopes es principal.role.scopes.map(s => s.slug), y Role.scopes es una relación muchos-a-muchos eager sobre role_scope indexada en user.roleSlug. Sin puerta de licencia, sin filtro, sin caché en ningún lugar de esa ruta, así que lo que imprimiste es exactamente lo que la tabla contiene para el rol al que tu usuario realmente apunta.

En 2.39.1 la lista de scopes del propietario tiene 176 entradas. Tienes 161, así que esto no es un scope que falte, son alrededor de quince, y workflow:update es solo el primero que casualmente probaste. Para que conste, la lista de propietarios de 2.36.7 es 163, así que tu tabla parece estar atrapada cerca de la forma que tenía mientras estabas degradado.

workflow:update se encuentra en la lista de propietarios tanto en 2.36.7 como en 2.39.1, así que su ausencia no es una diferencia de versión. Dos consultas:

SELECT id, email, "roleSlug" FROM "user";

SELECT s.slug FROM scope s
WHERE NOT EXISTS (
SELECT 1 FROM role_scope rs
WHERE rs.“scopeSlug” = s.slug AND rs.“roleSlug” = ‘global:owner’
);

Si roleSlug no es global:owner, ese es el problema completo. Si lo es, la segunda consulta lista lo que hay que volver a poner. Esas filas solo llegan a través de migraciones de una sola vez (AddWorkflowPublishScopeToProjectRoles, AddUnshareScopeToCustomRoles y amigos) y nada reconcilia role_scope al iniciar, por eso ninguna cantidad de reinicios o cambios de versión los devolvió.

6

Hola @itsmhashim
Una vez que la primera consulta confirme que tu usuario está en global:owner, vuelve a otorgar las filas faltantes en una sola declaración en lugar de insertarlas una por una:

INSERT INTO role_scope ("roleSlug", "scopeSlug")
SELECT 'global:owner', slug FROM scope
ON CONFLICT DO NOTHING;

Esto le da al propietario cada ámbito que existe, que es lo que el rol debe tener, así que cierra la brecha sin que tengas que averiguar cuáles faltaban. Cierra sesión e inicia sesión de nuevo después para que la sesión recoja la nueva lista.
Para el próximo downgrade, el camino documentado es ejecutar n8n db:revert en la versión que estás dejando, una migración por ejecución, antes de que inicie la imagen más antigua.

7

Hola @itsmhashim,

Veo en tu descripción que ejecutas instancias main y worker. ¿Actualizas todas las versiones de n8n de todas las instancias (workers y main) a la misma versión? Si no es así, diferentes versiones podrían competir por la definición del rol en la base de datos. Quizás puedas enviarme por mensaje directo la información de depuración de tu instancia. Gracias

8

Muchas gracias — esto está arreglado. Resultó ser exactamente lo que diagnosticaste: role_scope estaba genuinamente incompleto, no solo para global:owner sino también para project:personalOwner (137 de 190 faltantes — este era el bloqueador real del canvas) y un tercer rol que no había encontrado, workflow:owner (propiedad por flujo de trabajo, desde shared_workflow — 176 de 190 faltantes). Ejecuté la corrección INSERT … ON CONFLICT DO NOTHING en los tres, verifiqué mediante RETURNING, inicié sesión de nuevo, y el canvas es completamente editable ahora mismo.

9

Sí, actualicé todas las instancias a la misma versión.

10

¡Gracias por la ayuda, tío!