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]>
207 lines
6.8 KiB
TypeScript
207 lines
6.8 KiB
TypeScript
import { crmRequest, CrmError, VERSION_CALENDARS } from "./client.ts";
|
|
import type { CrmCtx } from "./ctx.ts";
|
|
|
|
export interface CrmCalendar {
|
|
id: string;
|
|
name: string;
|
|
isActive?: boolean;
|
|
calendarType?: string;
|
|
}
|
|
|
|
export interface CrmEvent {
|
|
id: string;
|
|
calendarId: string;
|
|
contactId?: string;
|
|
title?: string;
|
|
appointmentStatus?: string;
|
|
assignedUserId?: string;
|
|
startTime?: string;
|
|
endTime?: string;
|
|
}
|
|
|
|
export interface AltaCita {
|
|
calendarId: string;
|
|
contactId: string;
|
|
/** ISO con desplazamiento, no epoch. Ver `isoConDesplazamiento`. */
|
|
startTime: string;
|
|
endTime: string;
|
|
title: string;
|
|
assignedUserId?: string;
|
|
appointmentStatus?: string;
|
|
}
|
|
|
|
/**
|
|
* ISO con el desplazamiento horario del NEGOCIO.
|
|
*
|
|
* El CRM acepta `2026-09-03T11:00:00-06:00` en el alta de citas, y **no**
|
|
* milisegundos — al revés que el filtro de rango de `/calendars/events`, que sí
|
|
* los exige. Esa asimetría es de la API, no nuestra.
|
|
*
|
|
* Y no vale `toISOString()`: devuelve UTC con `Z`, y aunque el instante sea el
|
|
* mismo, la hora de pared que el CRM enseña en su interfaz sale de lo que se
|
|
* escribe aquí. Se construye con `Intl` y nunca con `new Date(y, m, d, …)`, que
|
|
* resuelve el reloj en la zona del proceso — el error que ya costó un fallo de
|
|
* producción en este repo (ver la sección de zonas horarias de CLAUDE.md).
|
|
*/
|
|
export function isoConDesplazamiento(d: Date, tz: string): string {
|
|
const zona = tz || "America/Mexico_City";
|
|
const p = new Intl.DateTimeFormat("en-CA", {
|
|
timeZone: zona,
|
|
year: "numeric",
|
|
month: "2-digit",
|
|
day: "2-digit",
|
|
hour: "2-digit",
|
|
minute: "2-digit",
|
|
second: "2-digit",
|
|
hour12: false,
|
|
}).formatToParts(d);
|
|
const g = (t: string) => p.find((x) => x.type === t)!.value;
|
|
|
|
const off = new Intl.DateTimeFormat("en-US", { timeZone: zona, timeZoneName: "longOffset" })
|
|
.formatToParts(d)
|
|
.find((x) => x.type === "timeZoneName")!.value;
|
|
const m = off.match(/GMT([+-])(\d{2}):(\d{2})/);
|
|
const desp = m ? `${m[1]}${m[2]}:${m[3]}` : "+00:00";
|
|
|
|
// `en-CA` con hour12:false puede rendir la medianoche como 24; el CRM espera 00.
|
|
const hora = g("hour") === "24" ? "00" : g("hour");
|
|
return `${g("year")}-${g("month")}-${g("day")}T${hora}:${g("minute")}:${g("second")}${desp}`;
|
|
}
|
|
|
|
/**
|
|
* Estado de la cita de la plataforma → estado del CRM.
|
|
*
|
|
* En la PETICIÓN el enum admite `new|confirmed|cancelled|showed|noshow|invalid`.
|
|
* En la respuesta hay dos más (`active`, `completed`) que el CRM asigna por su
|
|
* cuenta y no se pueden escribir.
|
|
*/
|
|
export function estadoCitaCrm(estado: string): string {
|
|
switch (estado) {
|
|
case "completed":
|
|
return "showed";
|
|
case "no_show":
|
|
return "noshow";
|
|
case "cancelled":
|
|
return "cancelled";
|
|
default:
|
|
return "confirmed";
|
|
}
|
|
}
|
|
|
|
export async function listarCalendarios(ctx: CrmCtx): Promise<CrmCalendar[]> {
|
|
const r = await crmRequest<any>("GET", "/calendars/", {
|
|
token: ctx.token,
|
|
query: { locationId: ctx.locationId },
|
|
version: VERSION_CALENDARS,
|
|
});
|
|
return r?.calendars ?? [];
|
|
}
|
|
|
|
/**
|
|
* El personal de la subcuenta.
|
|
*
|
|
* MEDIDO (hallazgo 35): esta ruta devolvía `401` cuando se midió por primera vez
|
|
* y hoy responde `200` con 6 usuarios. Da los ids que `staff[]` exige al crear
|
|
* servicios y `assignedUserId` al crear citas. Si vuelve a dar 401, quien llame
|
|
* debe poder seguir sin ella, no romperse.
|
|
*/
|
|
export async function listarPersonal(ctx: CrmCtx): Promise<{ id: string; name: string }[]> {
|
|
const r = await crmRequest<any>("GET", "/users/", {
|
|
token: ctx.token,
|
|
query: { locationId: ctx.locationId },
|
|
});
|
|
return (r?.users ?? []).map((u: any) => ({ id: u.id, name: u.name ?? "" }));
|
|
}
|
|
|
|
export async function obtenerCita(ctx: CrmCtx, eventId: string): Promise<CrmEvent | null> {
|
|
try {
|
|
const r = await crmRequest<any>("GET", `/calendars/events/appointments/${eventId}`, {
|
|
token: ctx.token,
|
|
version: VERSION_CALENDARS,
|
|
});
|
|
return (r?.event ?? r?.appointment ?? r) as CrmEvent;
|
|
} catch (e) {
|
|
if (e instanceof CrmError && e.status === 404) return null;
|
|
throw e;
|
|
}
|
|
}
|
|
|
|
/**
|
|
* Citas de un calendario en un rango.
|
|
*
|
|
* MEDIDO (hallazgo 28): sin `calendarId`, `userId` o `groupId` la API responde
|
|
* `422 Either of userId, calendarId or groupId is required`. No existe «dame
|
|
* todas las citas de la subcuenta»: hay que iterar los calendarios.
|
|
*
|
|
* El rango va en **milisegundos epoch**, al revés que el alta.
|
|
*/
|
|
export async function citasEnRango(
|
|
ctx: CrmCtx,
|
|
calendarId: string,
|
|
desdeMs: number,
|
|
hastaMs: number
|
|
): Promise<CrmEvent[]> {
|
|
const r = await crmRequest<any>("GET", "/calendars/events", {
|
|
token: ctx.token,
|
|
version: VERSION_CALENDARS,
|
|
query: {
|
|
locationId: ctx.locationId,
|
|
calendarId,
|
|
startTime: String(desdeMs),
|
|
endTime: String(hastaMs),
|
|
},
|
|
});
|
|
return r?.events ?? [];
|
|
}
|
|
|
|
export async function crearCita(ctx: CrmCtx, a: AltaCita): Promise<{ id: string }> {
|
|
const r = await crmRequest<any>("POST", "/calendars/events/appointments", {
|
|
token: ctx.token,
|
|
version: VERSION_CALENDARS,
|
|
body: {
|
|
// `locationId` va en el POST y ROMPE el PUT con 422. No reciclar el cuerpo
|
|
// del alta para actualizar: es la misma trampa ya medida en contactos.
|
|
locationId: ctx.locationId,
|
|
calendarId: a.calendarId,
|
|
contactId: a.contactId,
|
|
startTime: a.startTime,
|
|
endTime: a.endTime,
|
|
title: a.title,
|
|
appointmentStatus: a.appointmentStatus ?? "confirmed",
|
|
...(a.assignedUserId ? { assignedUserId: a.assignedUserId } : {}),
|
|
// La plataforma ya avisó a la clienta: que el CRM no dispare además sus
|
|
// automatizaciones y le llegue el mismo aviso dos veces.
|
|
toNotify: false,
|
|
// AgendaMax es la fuente de verdad del horario, y su base ya impide el
|
|
// solape con una restricción de exclusión. Que el CRM no rechace por su
|
|
// propia idea de disponibilidad, que no conoce la agenda real.
|
|
ignoreFreeSlotValidation: true,
|
|
},
|
|
});
|
|
const id = r?.id ?? r?.event?.id ?? r?.appointment?.id;
|
|
if (!id) throw new Error("El CRM aceptó la cita pero no devolvió su identificador");
|
|
return { id };
|
|
}
|
|
|
|
/** Actualiza una cita ya escrita. Sin `locationId` ni `contactId`: el PUT los rechaza. */
|
|
export async function actualizarCita(
|
|
ctx: CrmCtx,
|
|
eventId: string,
|
|
cambios: Partial<Omit<AltaCita, "contactId">>
|
|
): Promise<void> {
|
|
await crmRequest("PUT", `/calendars/events/appointments/${eventId}`, {
|
|
token: ctx.token,
|
|
version: VERSION_CALENDARS,
|
|
body: {
|
|
...(cambios.calendarId ? { calendarId: cambios.calendarId } : {}),
|
|
...(cambios.startTime ? { startTime: cambios.startTime } : {}),
|
|
...(cambios.endTime ? { endTime: cambios.endTime } : {}),
|
|
...(cambios.title ? { title: cambios.title } : {}),
|
|
...(cambios.appointmentStatus
|
|
? { appointmentStatus: cambios.appointmentStatus }
|
|
: {}),
|
|
toNotify: false,
|
|
},
|
|
});
|
|
}
|