fix: guardar el telefono en el formato que usa WhatsApp #5
Reference in New Issue
Block a user
Delete Branch "fix/telefono-formato-whatsapp"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
El problema
Un cliente registrado por la web no lo reconocia el bot de WhatsApp. El formulario aceptaba el telefono en cualquier formato (
1141984844,01157260394,11 4198-4844) pero Meta manda elwa_idcomo5491141984844, asi que la busqueda portelefonoNormno encontraba nada, mandaba al cliente al alta, y ahi chocaba contra el email ya registrado:Callejon sin salida. No lo agarraron ni los tests (que seedean
telefonoNormya normalizado) ni la revision con IA; aparecio al correr el bot contra una copia de la base de produccion.La solucion
El campo de telefono del registro muestra
+54 9fijo y grisado y el cliente completa solo la caracteristica (sin el 0) y el abonado (sin el 15): 10 digitos. Con eso el numero queda guardado igual alwa_id, sin heuristicas para adivinar prefijos.src/lib/telefono.ts:esLocalArgentinoValidoyaFormatoWhatsapp(prefijo549).src/components/ui/Input.tsx: props opcionalesprefijoyayuda. No cambia como se ve en los demas formularios.src/app/cliente/registro/page.tsx: filtra a digitos mientras se escribe, tope de 10, y avisa si empieza con 0 o si faltan digitos.src/app/api/cliente/registro/route.ts: valida el formato, guardatelefonoNormya en formato WhatsApp y rechaza un telefono repetido con 409 (antes reventaba contra el indice unico).La herramienta con la que se encontro
scripts/chat-bot.tspermite conversar con el bot desde la consola contra cualquier base, sin Meta ni credenciales, usando la misma funcion que invoca el webhook:Contra una copia del dump de produccion se verifico el ciclo completo: alta por web con el formato nuevo, el bot lo reconoce por telefono, pide el email de verificacion, rechaza el equivocado, acepta el correcto y sigue a elegir mecanico.
Pendiente aparte
Los 5 clientes que ya existen en produccion tienen
telefonoNormen null y siguen sin poder usar el bot. Son registros de prueba salvo quiza uno, y hay dos con el mismo telefono, asi que conviene decidir a mano si se limpian o se completan.🤖 Generated with Claude Code
Inline review
@@ -0,0 +34,4 @@const texto = linea.trim();if (texto === "/salir") break;if (texto === "/reset") {await prisma.conversacionWhatsapp.deleteMany({ where: { telefono } });El comando /reset usa el teléfono crudo del CLI, pero las conversaciones se guardan en formato WhatsApp (549...). Borrará 0 o la conversación equivocada.
#ai-review-inline
@@ -21,1 +25,4 @@{ status: 400 });const existe = await prisma.cliente.findUnique({ where: { email: email.toLowerCase() } });Condición de carrera: entre verificar email/teléfono y crear el cliente, otra request puede registrar los mismos datos. Usá una transacción o confía en constraints únicos de la BD.
#ai-review-inline
@@ -9,0 +18,4 @@* Parte local del número: característica sin el 0 y abonado sin el 15.* En Argentina son siempre 10 dígitos (ej: 11 4198-4844, 351 555-4444).*/export function esLocalArgentinoValido(local: string): boolean {La validación no rechaza números que empiezan con '15' (prefijo móvil antiguo). El comentario dice 'sin el 15' pero el código solo chequea '0'.
#ai-review-inline
Inline review
Inline review
Inline review
@@ -22,2 +29,4 @@if (existe) return NextResponse.json({ error: "El email ya está registrado" }, { status: 409 });// `telefonoNorm` queda igual al `wa_id` que manda Meta, que es como lo busca el bot.const telefonoNorm = aFormatoWhatsapp(telefono);Si llaman al API directo con un número que ya trae '549', normalizarTelefono lo deja y aFormatoWhatsapp le agrega otro '549'. El frontend lo evita (maxLength=10), pero el backend no se protege.
#ai-review-inline
@@ -19,0 +25,4 @@setForm((f) => ({ ...f, telefono: soloDigitos }));if (soloDigitos === "") setTelefonoError("");else if (soloDigitos.startsWith("0")) setTelefonoError("Sin el 0 de la característica");else if (soloDigitos.length < 10) setTelefonoError("Faltan dígitos (son 10 en total)");Muestra error 'Faltan dígitos' mientras el usuario está tipeando (antes de llegar a 10). Molesto. Mejor validar solo al blur o al submit.
#ai-review-inline
Inline review
Qué cambia
Se agrega validación y normalización de teléfonos argentinos en el registro de clientes: el frontend muestra prefijo fijo "+54 9" y acepta solo 10 dígitos (característica sin 0, abonado sin 15); el backend valida, normaliza y guarda tanto
telefono(solo dígitos) comotelefonoNormen formato WhatsApp (549 + 10 dígitos) para que coincida con elwa_idde Meta. También se creascripts/chat-bot.tspara probar el bot por consola contra la BD real.Riesgos
telefonoNormenClientey cambio de formato entelefono. Requiere migración de Prisma y backfill de clientes existentes; sin eso, registros previos quedarán inconsistentes y el bot no los reconocerá.esLocalArgentinoValidorechaza cualquier número que no sea 10 dígitos sin 0 inicial; si el producto se usa en otros países, rompe el registro.chat-bot.tsusaDATABASE_URLyprocesarMensajedirecto; si se ejecuta en prod o contra BD compartida, crea turnos y conversaciones reales.findFirst({ where: { telefonoNorm } })depende de índice único; confirmar que exista en migración.Antes de aprobar
telefonoNormcon índice único y haga backfill detelefonoNorm = '549' + normalizarTelefono(telefono)en clientes actuales.wa_id→telefonoNormy encuentra al cliente.chat-bot.tssolo está enscripts/y no se incluye en build/deploy; agregar guardiaif (process.env.NODE_ENV === 'production') process.exit(1)por seguridad.#ai-review-summary