DaraMex Docs

Appearance

Nexos — UI de conexiones (SMTP, Telegram y OAuth Google) ​

La ruta /connections (pestaña Nexos) muestra una vista de conexiones alineada visualmente con el diseño de referencia: cabecera, búsqueda, franja de tipos activos, catálogo de alta y (si aplica) otros tipos sin activas.

Comportamiento ​

  • Listado: GET /api/connections (respuesta validada con ConnectionSchema de @repo/schemas).
  • Catálogo de tipos (alta): GET /api/connections/available — cada fila incluye name (slug), metadatos y schema nullable:
    • Con schema (provider + fields): tipos por credenciales (p. ej. SMTP, Telegram). El panel muestra formulario dinámico y crea con POST /api/connections.
    • Con schema: null: tipos OAuth Google definidos por el slug name del catálogo (gmail, calendar, sheets en el seed actual). El panel muestra la misma rejilla de alta; el flujo de creación usa POST /api/connections/oauth/:provider/start (google_gmail o google_workspace) con cuerpo StartOAuthBodySchema (name, capability, visibility), y redirige al navegador a authUrl. Tras el callback de Google, la conexión queda creada en la API.
  • Agrupación en UI: además de provider, el panel usa una workspaceKey por fila de catálogo para no mezclar instancias de google_workspace con distinta capability (p. ej. Calendar vs Sheets). Las conexiones se asocian al tipo comparando provider y, para OAuth, config.capability.
  • Esquemas de formulario: para filas con schema, los campos vienen en available. Para instancias huérfanas sin fila de catálogo coincidente, el panel reutiliza esquemas embebidos en otras filas de la misma respuesta (providerSchemasFromAvailable).
  • Conexiones activas (franja horizontal): una tarjeta por entrada de catálogo con al menos una conexión activa que coincida con esa entrada. Configurar abre el workspace modal (lista + editor).
  • Workspace — credenciales: nombre, campos del esquema, Probar conexión, Guardar (POST /test / PUT según corresponda).
  • Workspace — OAuth: nueva instancia: nombre + Conectar con Google (mismo contrato que el diálogo de alta). Instancia existente: solo renombrar vía PUT con name (sin probar conexión tipo SMTP en el panel).
  • Alta desde catálogo (diálogo): credenciales → POST /api/connections; OAuth → botón Google, sin POST /connections directo desde el panel.
  • Edición / prueba / secretos enmascarados: igual que antes para tipos con formulario; ver guía de API para TestConnectionSchema y contraseñas enmascaradas.
  • Baja: DELETE /api/connections/:id.

Notas ​

  • Requiere permisos CASL de lectura/escritura sobre connections.connection como en la API.
  • La URL de callback OAuth y redirecciones post-login las define el backend (CONNECTIONS_OAUTH_*); el panel solo inicia el flujo y asigna window.location a authUrl.