Los formularios de alta y edicion tienen que guardar 0 como 0 y dejar NULL solo para el campo sin dato
Decision de Elazar 2026-09-03 sobre MOVILBA-191: el 0 del libro se guarda como 0 en las cinco columnas (ID CANBUS, ID ADAS, ID MDVR, Camaras_ADAS, Camaras_Internas) y NULL queda reservado para la celda VACIA. Sus palabras: "if camaras or whatever never gets a value is null but if it goes from 4 to 0 gets a 0, so we have null and 0, i say 0 to all". Escrito en docs/reference/rutap-transform-rules.md, regla T8, que quedo REVERTIDA respecto de su version anterior. ESTE ITEM ES LA MITAD DE UI DE ESA REGLA, y sin el la regla no existe. Elazar lo dijo explicito: "yet you have to make sure the add and edit forms use 0". EL PROBLEMA: un input numerico vaciado a mano manda cadena vacia, y la cadena vacia termina en NULL. Con la regla vieja daba igual porque los dos caminos colapsaban al mismo lugar. Ahora NO: NULL significa "nunca tuvo valor" y 0 significa "tiene valor y es cero". Un usuario que borra el 4 de Camaras_ADAS porque el colectivo ya no tiene camaras esta diciendo CERO, y hoy la app guarda "no sabemos". PANTALLAS: src/app/vehiculos/agregar/colectivo/page.tsx y src/app/vehiculos/[id]/editar/colectivo/page.tsx, mas cualquier action o servicio en el camino que colapse la cadena vacia a null (patrones tipo campo-o-null, doble-interrogacion-null, o un ternario sobre cadena vacia). En src/services/vehiculos.ts, updateColectivo, hay una tanda de comparaciones contra undefined que hay que leer con esto en la mano: undefined (no vino en el payload), cadena vacia (el usuario lo borro) y 0 (el usuario escribio cero) son TRES casos y hoy no se distinguen los tres. QUE TIENE QUE PASAR: 1. El formulario tiene que poder expresar las dos cosas: cero, y sin dato. Un input numerico vacio NO alcanza para las dos. Decidilo y decilo en el ticket antes de codear - la opcion barata es que vacio signifique sin dato y que el usuario escriba 0 para cero, con un texto de ayuda que lo diga. 2. El camino de escritura tiene que preservar el 0 hasta la base. Verificalo con una edicion real en DEV, no leyendo el codigo: poner 0, guardar, y consultar la fila. 3. Lo mismo para los identificadores, que son texto: el string cero es un valor y el string vacio es sin dato. NO ES ESTE TICKET: el backfill de DEV, que va por el carril de base de datos. Aca es solo la UI y el camino de escritura. CONTROL: hoy en el libro EMPTY y 0 no coexisten en ninguna de las cinco columnas (0 celdas vacias sobre 5319 filas con dominio), asi que la rama NULL no tiene ninguna fila que la ejerza y esta UNTESTED contra datos reales. Se prueba a mano.
Activity
-
was: Decision de Elazar 2026-09-03 sobre MOVILBA-191: el 0 del libro se guarda como 0 en las cinco columnas (ID CANBUS, ID ADAS, ID MDVR, Camaras_ADAS, Camaras_Internas) y NULL queda reservado para la celda VACIA. Sus palabras: 'if camaras or whatever never gets a value is null but if it goes from 4 to 0 gets a 0, so we have null and 0, i say 0 to all'. Escrito en docs/reference/rutap-transform-rules.md, regla T8, que quedo REVERTIDA respecto de su version anterior. ESTE ITEM ES LA MITAD DE UI DE ESA REGLA, y sin el la regla no existe. Elazar lo dijo explicito: 'yet you have to make sure the add and edit forms use 0'. EL PROBLEMA: un input numerico vaciado a mano manda cadena vacia, y la cadena vacia termina en NULL. Con la regla vieja daba igual porque los dos caminos colapsaban al mismo lugar. Ahora NO: NULL significa 'nunca tuvo valor' y 0 significa 'tiene valor y es cero'. Un usuario que borra el 4 de Camaras_ADAS porque el colectivo ya no tiene camaras esta diciendo CERO, y hoy la app guarda 'no sabemos'. PANTALLAS: src/app/vehiculos/agregar/colectivo/page.tsx y src/app/vehiculos/[id]/editar/colectivo/page.tsx, mas cualquier action o servicio en el camino que haga , o un ternario sobre cadena vacia. En src/services/vehiculos.ts:updateColectivo hay una tanda de que hay que leer con esto en la mano - undefined (no vino en el payload), cadena vacia (el usuario lo borro) y 0 (el usuario escribio cero) son TRES casos y hoy no se distinguen los tres. QUE TIENE QUE PASAR: 1. El formulario tiene que poder expresar las dos cosas: cero, y sin dato. Un input numerico vacio NO alcanza para las dos. Decidilo y decilo en el ticket antes de codear - la opcion barata es que vacio signifique sin dato y que el usuario escriba 0 para cero, con un texto de ayuda que lo diga. 2. El camino de escritura tiene que preservar el 0 hasta la base. Verificalo con una edicion real en DEV, no leyendo el codigo: poner 0, guardar, y consultar la fila. 3. Lo mismo para los identificadores, que son texto: '0' es un valor y '' es sin dato. NO ES ESTE TICKET: el backfill de DEV, que va por el carril de base de datos. Aca es solo la UI y el camino de escritura. CONTROL: hoy en el libro EMPTY y 0 no coexisten en ninguna de las cinco columnas (0 celdas vacias sobre 5319 filas con dominio), asi que la rama NULL no tiene ninguna fila que la ejerza y esta UNTESTED contra datos reales. Se prueba a mano.
-
coder03-mba-l-cc
-
Cerrado por coder03-mba-l-cc, commit 055d9c85, dev v5.4.108. EL DEFECTO NO ERA EL QUE EL TICKET DESCRIBIA. En services/vehiculos.ts, updateColectivo, camarasAdasCantidad y camarasInternasId pasaban por un toString opcional que colapsa el null explicito (el usuario vacio el campo) a undefined, y la guarda de upsertColectivo lee undefined como 'no toques la columna'. O sea el sintoma no era escribir NULL donde iba 0: era un NO-OP SILENCIOSO - el campo vaciado dejaba el valor viejo en la base. Eso es peor que lo que buscabamos y solo aparecio porque se ejercito el camino, no porque se leyera el codigo. El camino de alta y los campos de texto (ipCanbus, ipMdvr, identificacionCamarasAdas) ya estaban bien y no se tocaron. UI: texto de ayuda en alta y edicion, vacio = sin dato, 0 = confirmado. VERIFICACION EN DEV VIVO, no lectura de codigo: llamadas reales a updateColectivo sobre vehiculo_id=3344 con un SELECT por psql entre cada paso. Escribir 0 -> la base muestra 0. Escribir null -> la base muestra NULL, no el valor viejo. Restaurado el 1 original y confirmado. LO NO EJERCITADO: camarasInternasId comparte el camino pero no se corrio aparte, y los tres campos de texto se declararon correctos por lectura, sin escritura real. La rama NULL sigue sin ninguna fila del libro que la ejerza (0 celdas vacias en las cinco columnas). Pedido review a audit-mba-l-cc.
-
SEGUNDO DEFECTO, encontrado al cerrar las brechas de cobertura, commit c0ff22d6, dev v5.4.109. En el camino de alta, colectivoFields.ipCanbus = input.ipCanbus ?? '' (y lo mismo ipMdvr e identificacionCamarasAdas) colapsaba el null explicito a CADENA VACIA. Es la imagen espejo del primero: aquel era un no-op silencioso (no escribia), este escribe un valor no-nulo EQUIVOCADO. Verificado en DEV vivo antes y despues: antes, escribir null aterrizaba como '' con is_null=false; despues, aterriza como NULL real. Los tres campos arreglados, CreateColectivoData ampliado a string|null. ESTO CIERRA UNA PREGUNTA ABIERTA DE OTRO CARRIL: db02 midio hoy en PROD 4 cadenas vacias en ip_canbus y 3 en identificacion_camaras_adas y las reporto como un TERCER estado que la regla no nombra. Ya no es un estado sin explicar: tiene un escritor identificado. La regla sigue teniendo dos valores (0 = tiene valor y es cero, NULL = nunca tuvo valor); la cadena vacia era un defecto, no una tercera semantica. NO EJERCITADO EN VIVO: ipMdvr e identificacionCamarasAdas comparten el fix y el camino de ipCanbus pero no se corrieron aparte. Es argumento por camino de codigo, no medicion.