Normalizar valor_opcion a UPPER_SNAKE_CASE: 12 filas en minuscula (tipo_correo, tipo_telefono, ambito) contra la convencion de la API de Rendiciones
Elazar decidio 2026-08-28 que TODO valor enumerado viaja como UPPER_SNAKE_CASE en la API de Rendiciones (filtros y respuestas), siempre valor_opcion y nunca la etiqueta. Hoy el catalogo no cumple: 12 filas vivas de opciones tienen valor_opcion en minuscula, en 3 campos - tipo_correo 8 de 8 (facturacion, laboral, notificaciones, oficina, personal, registro, soporte, ventas), tipo_telefono 2 de 5 (fax, movil_personal; FIJO, FIJO_PERSONAL y MOVIL ya estan bien) y ambito 2 de 2. O la API pone mayusculas a la salida, o se normaliza el catalogo UNA vez. Recomiendo normalizar el catalogo: si la API lo hace a la salida, cada consumidor de valor_opcion queda en desacuerdo con los demas y el defecto se hereda para siempre. RADIO DE IMPACTO MEDIDO (db02-mba-l-cc, DEV y PROD): las columnas de negocio referencian por ID, no por texto - correos_electronicos.tipo_correo_id 37 filas DEV / 34 PROD, numeros_telefonicos.tipo_telefono_id 6 DEV / 4 PROD -, ninguna vista de public cita los literales, y ningun .ts/.tsx compara esas cadenas: lo unico que las toca las proyecta (v_ui_tipo_telefono, matviews v_tipo_correo/v_tipo_telefono) o usa el id. Las etiquetas de la UI salen de nombre_mostrable, que NO se toca. O sea: UPDATE de texto sobre 12 filas, sin FK que dependa del valor y sin comparacion literal que romper. NO es un cambio cosmetico aunque lo parezca: valor_opcion es el codigo de negocio que ahora viaja por una API externa, y el pedido de GO tiene que decir eso. Requiere GO explicito de Elazar, DEV primero y PROD como operacion aparte.
Activity
-
0
-
Elevado a prioridad 0 = espera GO de Elazar para PROD. DEV aplicado y verificado el 2026-08-28 (12 filas a UPPER_SNAKE_CASE, 0 no conformes vivas). PROD necesita GO propio y fresco: el de DEV no se arrastra.
-
RECOMENDACION ESCRITA (db02, 2026-09-03), que es lo que este item p0 estaba esperando. Todo re-medido hoy contra PROD y DEV; ninguna cifra viene heredada. RECOMIENDO: normalizar el CATALOGO, con un UPDATE de 12 filas sobre opciones. NO que la API ponga mayusculas a la salida. POR QUE NO LA API: valor_opcion es el codigo de negocio y la API de Rendiciones no es su unico lector. Si la mayuscula la pone la capa de salida, la base sigue diciendo 'facturacion' y la API dice 'FACTURACION', asi que cada consumidor nuevo tiene que aprender la conversion o queda en desacuerdo con los demas. El defecto se hereda para siempre y no deja rastro. Normalizar el dato lo arregla en un lugar. ESTADO MEDIDO HOY: DEV: 168 filas vivas en opciones, 0 no conformes. Ya aplicado el 08-28 y sigue limpio. PROD: 168 filas vivas, 12 no conformes. Son exactamente las mismas 12 del analisis original. LAS 12, con su destino y su etiqueta (la etiqueta NO se toca): ambito: interjurisdiccional, urbano tipo_correo: facturacion, laboral, notificaciones, oficina, personal, registro, soporte, ventas tipo_telefono: fax, movil_personal nombre_mostrable queda igual en las 12 ('Facturacion', 'Empresa', 'Movil personal', ...), asi que la UI no cambia una letra. RADIO DE IMPACTO RE-MEDIDO HOY, y las cifras del item estaban vencidas: las columnas de negocio referencian por ID, no por texto - correos_electronicos.tipo_correo_id son 42 filas (el item decia 34) y numeros_telefonicos.tipo_telefono_id es 1 (el item decia 4). Ninguna FK depende del texto. GREP DEL CODIGO, con control positivo porque un cero sin control no vale: busque los 12 literales entre comillas en todo src de dev/dev - CERO archivos. El control positivo sobre el mismo comando y el mismo arbol encuentra 'MOVIL' en varios archivos, asi que el patron alcanza el arbol y el cero es del mundo. (El primer intento devolvio cero TAMBIEN en el control: era el pathspec, no el codigo. Sin control lo habria publicado como hallazgo.) RIESGO REAL, para que el GO lo nombre: es un UPDATE de texto sobre 12 filas de un catalogo vivo de PROD, y valor_opcion viaja hoy por una API externa. No es cosmetico aunque lo parezca. Reversible con el UPDATE inverso, y no hay FK ni comparacion literal que rompa. TEXTO DE GO QUE HACE FALTA: 'GO para UPDATE opciones SET valor_opcion=upper(valor_opcion) sobre las 12 filas vivas no conformes de PROD (campos ambito, tipo_correo, tipo_telefono), sin tocar nombre_mostrable'. El GO de DEV no se arrastra. NO EJERCITADO: no llame a la API de Rendiciones para ver que devuelve hoy en esos campos, y no revise consumidores fuera de este repo.
-
PROD applied from commit 4caea8a0 after rollback rehearsal: 12 live opciones normalized and committed. Post-gates passed (0 invalid UPPER_SNAKE, 0 collisions); direct post-query confirms all 12 expected IDs.
-
Re-measured today: zero live rows with lowercase valor_opcion for tipo_correo/tipo_telefono/ambito on either DEV or PROD (checked with and without grupo_nombre filter). The 12 named in the ticket text are already normalized - not by this ticket, resolved elsewhere/upstream before today. Separate note, NOT this ticket's scope: audit's re-scan surfaced id 305/306 'QA658_grp/QA658_campo/QA658_val_*' on both envs - dead test residue (created+soft-deleted same second, 2026-07-03 14:04, same creado_por/timestamps on both envs from the 2026-08-12 dev->prod seed copy). borrado_en is set on both, not live, no query surfaces them - not actionable, no new item filed.