feat(platform): multi-tenancy con credenciales por negocio y sincronización por id

El backend Postgres de `platform/` asumía un solo negocio con un solo token del CRM. Este cambio lo convierte en una plataforma multi-cuenta y añade la sincronización selectiva de las cinco entidades del encargo. ## Multi-tenancy El `locationId` ya era por negocio, pero el token vivía en la variable de entorno `CRM_TOKEN`, una sola para todo el proceso. Con dos negocios eso usaba el token del primero contra la subcuenta del segundo: 401 en el mejor caso, escritura en la subcuenta equivocada en el peor. - `lib/crypto.ts` — AES-256-GCM para los tokens. Autenticado a propósito: una fila manipulada hace que el descifrado FALLE, en vez de devolver basura que acabaríamos mandando como credencial al CRM. La clave maestra vive en `CRM_MASTER_KEY`, fuera de la base. - `crm/ctx.ts` — `CrmCtx { businessId, locationId, token }` sustituye al `locationId: string` suelto que viajaba por once firmas. Es un objeto y no dos parámetros porque dos `string` seguidos se cruzan sin que el compilador diga nada, y cruzarlos aquí manda el token de un cliente a la subcuenta de otro. Es el único sitio donde el token existe descifrado, y solo en memoria. - `crm/client.ts` — `CrmOptions.token` pasa a ser OBLIGATORIO, sin valor por defecto: olvidarlo es ahora un error de compilación. El estrangulador pasa a ser por token y aprende la cuota de las cabeceras `x-ratelimit-*`, que declaran 100 peticiones por 10 s — el cliente iba 6,5x por debajo con una estimación. - Migración 003: credencial cifrada, calendario y la red de seguridad de mensajes POR NEGOCIO. Como variable global decidía por todas las cuentas a la vez. Lo único de la credencial que sale del servidor es la huella de 6 caracteres. ## Consola de superadministración `/api/admin`, solo para el rol `admin`: alta de cuentas con su dueña en una transacción, vínculo, desvínculo y suspensión. Las credenciales se COMPRUEBAN contra el CRM antes de guardarse — un token sin validar traslada el fallo al primer intento de sincronizar, lejos de donde se cometió. El error distingue «token inválido» de «subcuenta inexistente» de «token de otra subcuenta». Pantalla en `/admin/cuentas`, verificada en navegador: el campo del token es de contraseña y viene vacío, porque no hay valor que traer. ## Sincronización por identificador `POST /api/crm/sync/:entidad/:id` para contacto, conversación, mensaje, cita y servicio. La dirección la decide la entidad: las tres primeras se TRAEN porque el CRM es su dueño; las dos últimas se EMPUJAN, porque el calendario del CRM tiene una sola cita en dos años y su catálogo de servicios está vacío. - `crm/conversations.ts` — lectura por id de conversaciones y mensajes sueltos. - `crm/syncConversations.ts` — el espejo persistido. Las tablas existían desde 002_crm.sql y nadie escribía en ellas: la bandeja consultaba el CRM en vivo. - `crm/calendars.ts` — escritura de citas al calendario. `isoConDesplazamiento` escribe la hora de pared del negocio con su desplazamiento; `toISOString()` habría movido la hora que el CRM enseña en su interfaz. - `crm/services.ts` — publicación de servicios al catálogo. ## Verificado contra la subcuenta real, no deducido Las cinco entidades se ejercieron contra el CRM del cliente. Las escrituras van en un ciclo crear → releer → borrar → confirmar borrado, con la limpieza en un `finally`, y antes se comprobó que el borrado existe: preguntar si se puede deshacer ANTES de escribir en el CRM de un cliente, no después. La subcuenta quedó como estaba. 47 hallazgos medidos en `crm/HALLAZGOS.md`, y la referencia de endpoints en `crm/API.md`, con la lista explícita de dónde la documentación oficial falla. 110 pruebas de plataforma en verde, typecheck limpio, build correcto. El backend de demo de `server/` no se ha tocado y sigue con sus 43 pruebas. ## Deuda conocida, dicha sin rodeos - La bandeja de mensajes todavía lee en vivo del CRM, no del espejo. - La autenticación sigue siendo el id del usuario en texto plano, también para el rol admin. Esta consola crea cuentas y guarda credenciales de clientes encima de esa base: no debe quedar expuesta a internet hasta endurecerla. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-08-30 15:07:20 -06:00
parent dcbf750c09
commit 6d67b23e55
95 changed files with 16132 additions and 41 deletions
@@ -0,0 +1,140 @@
+import { Router } from "express";
+import { pool, withTx } from "../db/pool.ts";
+import { writeAudit } from "../lib/audit.ts";
+import { err, h, type AuthedRequest } from "../lib/auth.ts";
+import { bizDayBoundsIsoFor, bizTodayISO, DEFAULT_TZ } from "../../server/lib/time.ts";
+
+export const dayCloseRouter = Router();
+
+const APPT_COLS = `a.id, a.client_id, a.employee_id, a.service_id,
+  to_char(a.start_at AT TIME ZONE 'UTC', 'YYYY-MM-DD"T"HH24:MI:SS"Z"') AS start_at,
+  to_char(a.end_at   AT TIME ZONE 'UTC', 'YYYY-MM-DD"T"HH24:MI:SS"Z"') AS end_at,
+  a.status, a.price, c.name AS client_name, e.name AS employee_name, s.name AS service_name`;
+
+// `bizDayBoundsIsoFor` devuelve un fin INCLUSIVO (23:59:59 hora local), así que
+// la comparación es `<=`. Con `<` se perdería la última cita del día.
+const IN_DAY = `a.start_at >= $2::timestamptz AND a.start_at <= $3::timestamptz`;
+
+const UNRESOLVED_SQL = `
+  SELECT ${APPT_COLS} FROM appointments a
+    JOIN clients   c ON c.id = a.client_id
+    JOIN employees e ON e.id = a.employee_id
+    JOIN services  s ON s.id = a.service_id
+   WHERE a.business_id = $1 AND ${IN_DAY} AND a.status = 'scheduled'
+   ORDER BY a.start_at`;
+
+const COUNTS_SQL = `
+  SELECT
+     count(*) FILTER (WHERE status = 'completed')::int AS attended,
+     count(*) FILTER (WHERE status = 'no_show')::int   AS no_show,
+     count(*) FILTER (WHERE status = 'cancelled')::int AS cancelled
+    FROM appointments
+   WHERE business_id = $1
+     AND start_at >= $2::timestamptz AND start_at <= $3::timestamptz`;
+
+async function bizTz(businessId: number): Promise<string> {
+  const { rows } = await pool.query(`SELECT timezone FROM businesses WHERE id = $1`, [
+    businessId,
+  ]);
+  return rows[0]?.timezone || DEFAULT_TZ;
+}
+
+dayCloseRouter.get(
+  "/",
+  h(async (req: AuthedRequest, res) => {
+    const bid = req.user!.business_id!;
+    const tz = await bizTz(bid);
+    const date = (req.query.date as string | undefined) || bizTodayISO(tz);
+    if (!/^\d{4}-\d{2}-\d{2}$/.test(date)) {
+      err(res, 400, "Fecha no válida");
+      return;
+    }
+    const { start, end } = bizDayBoundsIsoFor(tz, date);
+
+    const unresolved = await pool.query(UNRESOLVED_SQL, [bid, start, end]);
+    const counts = await pool.query(COUNTS_SQL, [bid, start, end]);
+    const closure = await pool.query(
+      `SELECT closed_at FROM day_closures WHERE business_id = $1 AND business_date = $2::date`,
+      [bid, date]
+    );
+
+    res.json({
+      date,
+      closed_at: closure.rows[0]?.closed_at ?? null,
+      unresolved: unresolved.rows,
+      attended: counts.rows[0].attended,
+      no_show: counts.rows[0].no_show,
+      cancelled: counts.rows[0].cancelled,
+    });
+  })
+);
+
+dayCloseRouter.post(
+  "/",
+  h(async (req: AuthedRequest, res) => {
+    const bid = req.user!.business_id!;
+    const tz = await bizTz(bid);
+    const date = (req.body?.date as string | undefined) || bizTodayISO(tz);
+    if (!/^\d{4}-\d{2}-\d{2}$/.test(date)) {
+      err(res, 400, "Fecha no válida");
+      return;
+    }
+
+    const { start, end } = bizDayBoundsIsoFor(tz, date);
+
+    const ya = await pool.query(
+      `SELECT 1 FROM day_closures WHERE business_id = $1 AND business_date = $2::date`,
+      [bid, date]
+    );
+    if (ya.rows[0]) {
+      err(res, 409, "Ese día ya está cerrado");
+      return;
+    }
+
+    // La regla que sostiene todo el proyecto: no se puede cerrar el día dejando
+    // citas sin desenlace. Es lo que convierte el registro en el camino más
+    // corto para trabajar, en vez de una tarea añadida al final.
+    const pend = await pool.query(UNRESOLVED_SQL, [bid, start, end]);
+    if (pend.rows.length) {
+      res.status(409).json({
+        error: `Quedan ${pend.rows.length} cita(s) sin resolver: marca si vinieron o no antes de cerrar`,
+        unresolved: pend.rows,
+      });
+      return;
+    }
+
+    const closure = await withTx(async (c) => {
+      const counts = await c.query(COUNTS_SQL, [bid, start, end]);
+      const { rows } = await c.query(
+        `INSERT INTO day_closures
+           (business_id, business_date, closed_by_user_id,
+            attended_count, no_show_count, cancelled_count)
+         VALUES ($1,$2::date,$3,$4,$5,$6)
+         RETURNING id, business_id,
+                   to_char(business_date, 'YYYY-MM-DD') AS business_date,
+                   closed_by_user_id, closed_at,
+                   attended_count, no_show_count, cancelled_count`,
+        [
+          bid,
+          date,
+          req.user!.id,
+          counts.rows[0].attended,
+          counts.rows[0].no_show,
+          counts.rows[0].cancelled,
+        ]
+      );
+      await writeAudit(c, {
+        businessId: bid,
+        actorUserId: req.user!.id,
+        entity: "day_closures",
+        entityId: rows[0].id,
+        action: "close",
+        after: rows[0],
+        ip: req.ip ?? null,
+      });
+      return rows[0];
+    });
+
+    res.json({ closure });
+  })
+);