El prospecto de GlobalLink, dentro del sistema de TNI

Objetivo. Autorizar por escrito las altas descritas en el addendum COT-0003-A1 versión 2, que ya está redactado y no requiere cambios de nuestro lado.

Qué se firma. El documento «Addendum COT-0003-A1 · Autorización de write-back limitado, versión 2 del 20 de agosto de 2026». Firman José Lutz por Truly Nolen International y Pablo Estrada por AI Catalysts. Autoriza únicamente altas en cuatro tablas de tres bases, prohíbe modificar y borrar, y puede suspenderse por correo con efecto inmediato.

Qué hacemos nosotros con él. Depositamos el PDF firmado en el servidor de la plataforma, en la ruta /etc/tn-globallink/writeback-addendum-firmado. El programa de escritura verifica que ese archivo exista y no esté vacío antes de cada corrida; si no está, no emite ninguna alta y lo deja escrito en su registro.

Criterio de aceptación. PDF firmado por ambas partes, en cualquier formato de firma. No hace falta plataforma de firma electrónica.

Una salvedad, para que quede escrita. El texto del addendum describe idempotency_key como columna obligatoria. En la práctica se aplica como nula con índice único filtrado (R4) —de otro modo fallaría sobre las filas que ya existen— y, además, R4 pasó a ser opcional. No cambia el alcance autorizado ni las tablas afectadas; si prefieren corregir esa línea antes de firmar, lo hacemos en el día.

Qué no hace falta. Ningún anexo técnico nuevo: el memo que lo acompaña ya está entregado.

Objetivo. Un login nuevo, distinto del lector, que sólo pueda insertar en cuatro tablas de las tres bases productivas.

Por qué uno nuevo y no ampliar el actual. Para poder revocar la escritura sin tocar la lectura, y para que cualquier auditoría vea en el catálogo de permisos exactamente qué puede hacer cada uno.

Objetos a crear. Un login de servidor y tres usuarios de base, uno por base:

Por qué también SELECT. Porque el alta devuelve el número asignado con OUTPUT INSERTED.IdCliente, y sin permiso de lectura sobre esa tabla el motor rechaza la cláusula. El SELECT se limita a esas cuatro tablas; el resto de la base queda fuera.

Script, listo para ejecutar. La contraseña la generan ustedes y nos la entregan por la bóveda de secretos, nunca por correo ni por chat:

/* ---------- 1) una sola vez, en la instancia ---------- */
USE [master];
GO
CREATE LOGIN [user_globallink_writer]
  WITH PASSWORD = N'<la que ustedes generen>',
       CHECK_POLICY = ON,
       CHECK_EXPIRATION = OFF,
       DEFAULT_DATABASE = [Truly];
GO

/* ---------- 2) repetir el bloque completo en Truly, TrulyNew y TrulyRuso ---------- */
USE [Truly];   -- luego [TrulyNew], luego [TrulyRuso]
GO
CREATE USER [user_globallink_writer] FOR LOGIN [user_globallink_writer];
GO
GRANT INSERT, SELECT ON [dbo].[Clientes]   TO [user_globallink_writer];
GRANT INSERT, SELECT ON [dbo].[Contactos]  TO [user_globallink_writer];
GRANT INSERT, SELECT ON [dbo].[Servicios]  TO [user_globallink_writer];
GRANT INSERT, SELECT ON [dbo].[Propuestas] TO [user_globallink_writer];
GO
DENY UPDATE, DELETE ON [dbo].[Clientes]   TO [user_globallink_writer];
DENY UPDATE, DELETE ON [dbo].[Contactos]  TO [user_globallink_writer];
DENY UPDATE, DELETE ON [dbo].[Servicios]  TO [user_globallink_writer];
DENY UPDATE, DELETE ON [dbo].[Propuestas] TO [user_globallink_writer];
GO

Verificación. Ejecutar en cada base conectado como ese usuario. Devuelve una fila por tabla y permiso, incluidas las denegaciones: tienen que salir dieciséis filas — ocho GRANT de INSERT y SELECT, y ocho DENY de UPDATE y DELETE. Las ocho de DENY son la prueba de que la restricción quedó puesta, no un defecto:

SELECT o.name AS tabla, p.permission_name, p.state_desc
FROM   sys.database_permissions p
JOIN   sys.objects o ON o.object_id = p.major_id
WHERE  p.grantee_principal_id = DATABASE_PRINCIPAL_ID('user_globallink_writer')
ORDER BY o.name, p.permission_name;

-- y la prueba negativa: esto TIENE que fallar con error 229
UPDATE dbo.Clientes SET Observaciones = Observaciones WHERE 1 = 0;

Criterio de aceptación. Las dieciséis filas —ocho concedidas y ocho denegadas— y el error 229 en la prueba negativa. Nosotros repetimos la misma verificación desde nuestro servidor y la dejamos en el registro de la primera corrida.

Qué no hacer. No agregar el usuario a db_datawriter ni a ningún rol fijo: eso le daría escritura sobre toda la base. No darle EXECUTE sobre procedimientos. No crearlo en TrulyGestion. No reutilizar la contraseña del lector.

Objetivo. Que las conexiones de ese usuario, desde nuestra única dirección, lleguen al puerto del motor.

Cómo se comprueba, y por qué hacen falta los dos lados. Esta regla es la única de las tres que no se puede verificar desde dentro de su red: una prueba de conexión lanzada desde su propio servidor devuelve «conectado» con la regla puesta o sin ella, porque no atraviesa el firewall. Se comprueba en dos pasos:

1 · Ustedes, que el motor escucha. Desde el servidor de base de datos, confirma que el puerto es el correcto y que la instancia responde. No prueba la regla:

Test-NetConnection -ComputerName localhost -Port 11433
# TcpTestSucceeded : True → el motor escucha en 11433

2 · Nosotros, que la regla deja entrar. Abrimos una conexión desde la IP autorizada con el usuario de R2, en modo sombra, sin insertar nada, y les confirmamos el resultado el mismo día. Es lo único que prueba de verdad que la lista blanca quedó bien.

Criterio de aceptación. Nuestra conexión entra desde la IP autorizada, y falla desde cualquier otra. Ese par —entra una, no entran las demás— es lo que demuestra que es una lista blanca y no una apertura general. Se lo pasamos por escrito el mismo día.

Qué no hacer. No abrir el puerto a rangos amplios ni a Internet. Si su política exige VPN en lugar de lista blanca, decirlo y coordinamos: el programa corre en un servidor fijo y puede usar un túnel.

Objetivo. Que si nuestro programa reintenta un alta que en realidad ya entró (corte de red justo después del INSERT), sea el propio motor de SQL Server el que rechace la segunda.

Corrección del 4 de septiembre: esto dejó de ser opcional. En la versión anterior de este documento lo presentamos como «una mejora para ustedes, que nosotros no necesitamos». Era una lectura incompleta y la corregimos acá. Es cierto que la protección contra duplicados funciona sin esta columna: antes de insertar comparamos contra la cartera de la oficina y marcamos cada alta con el identificador del negocio dentro del texto de Observaciones. Pero eso resuelve nuestro problema, no el suyo. Mientras el identificador viva dentro de un texto libre, el negocio no existe como dato en su base: no se puede consultar, no se puede indexar, y no se puede cruzar con nada. Y en dbo.Propuestas, que no tiene columna de observaciones, directamente no queda ningún rastro. Esta columna es la única forma de que un prospecto creado por GlobalLink tenga identidad propia del lado de TNI. Sigue sin bloquear la primera escritura —si no está, escribimos igual—, pero ya no la presentamos como prescindible. El detalle está en 5.1.

Objetos a crear. Doce columnas y doce índices: cuatro tablas por cada una de las tres bases.

Por qué nula y con índice filtrado, y no obligatoria. El texto del addendum la describe como obligatoria. Aplicarla así fallaría: las filas que ya existen no tienen clave, y una columna obligatoria sin valor por omisión no se puede agregar a una tabla con datos. La forma de acá deja el histórico intacto, el índice sólo mira las filas que traen clave, y el efecto anti-duplicado es el mismo. Es una mejora sobre el texto firmado, no una desviación que haya que documentar: el addendum autoriza altas, y esta columna sólo las hace más seguras. Como además es opcional, no cambia nada de lo firmado.

Script, listo para ejecutar. Repetir el bloque completo en Truly, TrulyNew y TrulyRuso:

USE [Truly];   -- luego [TrulyNew], luego [TrulyRuso]
GO
ALTER TABLE [dbo].[Clientes]   ADD [idempotency_key] UNIQUEIDENTIFIER NULL;
ALTER TABLE [dbo].[Contactos]  ADD [idempotency_key] UNIQUEIDENTIFIER NULL;
ALTER TABLE [dbo].[Servicios]  ADD [idempotency_key] UNIQUEIDENTIFIER NULL;
ALTER TABLE [dbo].[Propuestas] ADD [idempotency_key] UNIQUEIDENTIFIER NULL;
GO
CREATE UNIQUE NONCLUSTERED INDEX [UX_Clientes_idempotency_key]
  ON [dbo].[Clientes]   ([idempotency_key]) WHERE [idempotency_key] IS NOT NULL;
CREATE UNIQUE NONCLUSTERED INDEX [UX_Contactos_idempotency_key]
  ON [dbo].[Contactos]  ([idempotency_key]) WHERE [idempotency_key] IS NOT NULL;
CREATE UNIQUE NONCLUSTERED INDEX [UX_Servicios_idempotency_key]
  ON [dbo].[Servicios]  ([idempotency_key]) WHERE [idempotency_key] IS NOT NULL;
CREATE UNIQUE NONCLUSTERED INDEX [UX_Propuestas_idempotency_key]
  ON [dbo].[Propuestas] ([idempotency_key]) WHERE [idempotency_key] IS NOT NULL;
GO

Impacto medido. ALTER TABLE ADD de una columna nula es un cambio de metadatos: no reescribe las filas. Sobre Clientes de Truly son 464.278 filas y la operación es inmediata. Los cuatro índices se crean vacíos, porque ninguna fila existente tiene clave. Su aplicación no necesita conocer la columna: no aparece en ningún SELECT * de pantalla porque es nueva y nula.

Verificación. En cada base, tiene que devolver cuatro filas con is_nullable = 1 y cuatro índices has_filter = 1:

SELECT t.name AS tabla, c.name AS columna, c.is_nullable, ty.name AS tipo
FROM   sys.columns c
JOIN   sys.tables  t  ON t.object_id = c.object_id
JOIN   sys.types   ty ON ty.user_type_id = c.user_type_id
WHERE  c.name = 'idempotency_key'
ORDER BY t.name;

SELECT t.name AS tabla, i.name AS indice, i.is_unique, i.has_filter, i.filter_definition
FROM   sys.indexes i
JOIN   sys.tables  t ON t.object_id = i.object_id
WHERE  i.name LIKE 'UX_%_idempotency_key'
ORDER BY t.name;

Criterio de aceptación. Cuatro columnas y cuatro índices por base, doce y doce en total. Nosotros lo confirmamos porque la columna aparece en el catálogo que leemos cada noche.

Qué no hacer. No ponerla obligatoria. No crear el índice sin el filtro WHERE … IS NOT NULL: sin él, un solo valor nulo por tabla sería admitido y el resto rechazado. No agregarla a TrulyGestion.

Objetivo. Que el prospecto que escribimos se vea exactamente como los que inscribe su gente. Estas tres convenciones ya están decididas y en construcción: el 3 de septiembre leímos su catálogo y medimos cómo llenan los campos sobre los 1.268 prospectos de la oficina de Guatemala, y elegimos en consecuencia. Esta sección existe para que sepan exactamente qué vamos a escribir y por qué, con la consulta al lado para que puedan comprobarlo. No estamos esperando una respuesta. Si alguna de las tres no les cuadra, un correo y se cambia: es una constante del programa, cuesta un minuto.

-- comprueben lo anterior en un minuto
USE [Truly];
SELECT s.IdStatusCliente, s.StatusCliente_01 AS ingles, s.StatusCliente_02 AS espanol,
       COUNT(c.IdCliente) AS clientes_en_la_679
FROM   dbo.AuxStatusClientes s
LEFT   JOIN dbo.Clientes c ON c.IdStatusCliente = s.IdStatusCliente AND c.IdOficina = 679
GROUP  BY s.IdStatusCliente, s.StatusCliente_01, s.StatusCliente_02
ORDER  BY s.IdStatusCliente;

-- comprueben que la columna se llena siempre, y con qué
USE [Truly];
SELECT COUNT(*) AS prospectos,
       SUM(CASE WHEN LTRIM(RTRIM(ISNULL(Identidad,''))) = '' THEN 1 ELSE 0 END) AS sin_identidad
FROM   dbo.Clientes
WHERE  IdOficina = 679 AND IdStatusCliente = 5;

Cómo lo van a ver. Antes de escribir nada en firme les mostramos la primera alta de prueba con estos tres valores puestos, sobre un prospecto real de Guatemala. Ahí se ve el resultado, no la promesa.

Por qué no se lo preguntamos. Porque ya teníamos con qué decidirlo: su propia base. Devolverles una pregunta que nosotros podíamos contestar sería trasladarles trabajo y sumar una espera al proyecto. Lo único que de verdad no podemos hacer sin ustedes es escribir, y eso depende de R1, R2 y R3.

Objetivo. Una pestaña más en la barra donde hoy están «Home» y «Reports», a la derecha de ellas.

Va junto con R7 y, como aquélla, no bloquea nada ni tiene fecha comprometida.

Dónde. En la plantilla que dibuja esa barra. En la instalación actual la barra se arma en /proposals/TG/includes/inc_menu_superior.asp, que es el archivo que aparece en el error cuando una página se abre fuera de su flujo. Si la plantilla real es otra, es la que corresponda: el requisito es que la pestaña salga en todas las pantallas del sistema.

Qué entregamos nosotros. El icono del ratón de Truly Nolen en SVG y en PNG de 16 y 32 píxeles (el de 32 es para pantallas de alta densidad), y este fragmento, adaptable a los estilos de su barra:

<a class="tab" href="/proposals/TG/globallink.asp"   <!-- .aspx si la hacen en ASP.NET -->
   target="_blank" rel="noopener noreferrer">
  <img src="/proposals/TG/img/tn-globallink.png" width="16" height="16" alt="" />
  Truly Nolen GlobalLink &#8599;
</a>

Las dos rutas van absolutas, y esto importa. Este fragmento vive en un archivo que se incluye desde todas las pantallas del sistema. Una ruta relativa se resuelve contra la dirección de la pantalla que la pide, no contra la del archivo incluido: desde /proposals/TG/reports/… el enlace apuntaría a /proposals/TG/reports/globallink.asp, que no existe, y el icono no cargaría. Con la barra inicial funciona igual desde cualquier pantalla. Si su instalación cuelga de otra carpeta, es esa ruta con barra inicial.

Reglas. La pestaña apunta a la página de R7, dentro de su propio sitio, nunca directamente a GlobalLink. Se abre en una pestaña nueva, para que la persona no pierda lo que estaba haciendo. La flecha avisa que sale del sistema.

Quién la ve. Ésta sí es decisión suya, porque es su menú y su gente. Nuestra recomendación, si no quieren pensarlo: los mismos perfiles que hoy ven el módulo de ventas. Si prefieren empezar sólo con Guatemala, basta condicionar la pestaña a IdPais = 244 mientras dure el piloto.

Criterio de aceptación. Con el usuario de prueba que ya tenemos, la pestaña aparece y abre la página de R7.

Objetivo. Que un empleado que ya inició sesión en el sistema de gestión llegue a GlobalLink identificado, sin escribir otra contraseña. Junto con la pestaña de R6, es el único desarrollo del lado de TNI, y desde el 4 de septiembre es sólo una página: ya no hay tabla que crear ni permiso que dar.

El contrato del token · lo que su emisor produce

Cabecera. {"alg":"HS256","typ":"JWT"}. Cualquier otro algoritmo —incluido none— se rechaza antes de mirar el contenido.

Payload. Éste es el ejemplo que nos mandaron, y es exactamente lo que vamos a leer:

{
  "Id":       12345,                       ← dbo.Empleados.IdEmpleado (confirmar)
  "Nombre":   "Roberto",
  "Apellido": "Gonzalez",
  "Email":    "rgonzalez@trulynolen.com",
  "Idioma":   "01",                        ← el número de columna TextoNN · ver 8.9
  "BD":       "Truly",                     ← Truly · TrulyNew · TrulyRuso (su ejemplo decía TrulyGestion: ver abajo)
  "iat":      1893456000,
  "exp":      1893456120                   ← 120 s después. Coincide con nuestros 2 minutos
}

Cómo viaja · POST, no en la dirección

El token lleva nombre y correo en base64, no cifrados: cualquiera que lo vea lo lee. Si viajara en la dirección (?token=…) quedaría escrito en registros de servidores, en el historial del navegador y en cualquier proxy intermedio. Por eso se envía por POST, con un formulario que se envía solo al cargar. Es lo mismo que ya hacía el fragmento que les dimos; sólo cambia el nombre del campo:

<form id="ir" method="post" action="https://app.trulynolen.tech/globalink/auth/exchange">
  <input type="hidden" name="token" value="<%= tokenFirmado %>">
</form>
<script>document.getElementById("ir").submit();</script>

Mientras la definitiva no exista, la misma página apunta a /globalink/pase-prueba (ver 8.10), que ya está viva y acepta este mismo formulario.

El secreto · quién lo genera, cómo llega, quién lo cuida

Lo generan ustedes, con al menos 32 bytes aleatorios (openssl rand -base64 48 sirve). Nos lo mandan por Bitwarden Send, igual que el usuario de SQL: un enlace de una sola vista. Nunca por correo, chat ni documento. De nuestro lado entra a una bóveda que lo distribuye a los dos programas que lo necesitan y a nada más; no se escribe en código, no se imprime en registros. Rotarlo es: ustedes generan uno nuevo, nos lo mandan igual, coordinamos la hora del cambio, y desde ese momento los tokens firmados con el viejo dejan de entrar.

Cómo se prueba · sin esperarnos

Apunten su formulario a https://app.trulynolen.tech/globalink/pase-prueba. Devuelve una página con las comprobaciones una por una —algoritmo, firma, vigencia, campos, base— y lo que entendió del token. Hasta que nos manden el secreto, dice «firma no verificada» y muestra el resto; en cuanto el secreto esté en nuestra bóveda, la misma dirección verifica la firma sin que ustedes cambien nada. Si ven su nombre, su correo, su idioma y su cargo correctos, su parte está terminada.

Lista de verificación de R7

Objetivo. Definir qué puede hacer en GlobalLink cada cargo de su tabla de empleados. Ya está definida y ya está cargada (4-sep-2026) en la tabla app.tni_cargo_rol de nuestro lado, así: leímos su catálogo de 43 cargos del espejo con la cantidad de empleados activos de cada uno. Diez tienen gente, y son los que van en la tabla de abajo, cada uno con su rol asignado. Los otros 33 no tienen ningún empleado activo, así que quedan sin rol: el día que TNI le asigne alguien a uno de ellos, esa persona no entrará hasta que agreguemos la fila, que es una línea en una tabla nuestra. No hace falta que preparen nada ni que respondan. La publicamos acá porque es una decisión sobre permisos de su gente y ustedes tienen que poder verla y objetarla; si una fila no corresponde, un correo y se corrige.

Con esta propuesta entran 2.018 personas de la red —la suma de la columna «Activos» de las filas con rol— y quedan fuera los 2.667 técnicos de campo, que no usan un sistema de ventas. Los números salen de su propia tabla de empleados, contando sólo los que no tienen fecha de baja. Su catálogo tiene 43 cargos; los 33 que no aparecen acá no tienen ningún empleado activo.

Qué hacemos con esto. La cargamos tal cual en una tabla nuestra, app.tni_cargo_rol. Un cargo que no esté en la lista no entra: el acceso se rechaza con un mensaje claro y nunca se adivina un rol. Cambiar una fila después es una línea en esa tabla, sin desplegar nada.

Lo que sí les pedimos que miren. Dos filas, porque son decisiones de negocio y no técnicas: los 2.667 técnicos de campo, que dejamos fuera porque no usan un sistema de ventas, y los 71 «Otro», que quedan fuera por precaución. Si alguno de esos grupos debería entrar, dígannos y lo cambiamos.