Estamos en la versión 3.22 y nos encontramos con que en la operación de Aceptar Trámites de Certificación, no aparecen habilitados los botones de Administrar Requisitos, Aceptar o Devolver.
Mirando en el código, veo que lo que está tomando en $datos[$fila][‘estado_requisitos’] viene en null para todos los registros (en la tabla sga_certificados_otorg) el campo está en ‘P’.
Hay que configurar algún parámetro o hay alguna condición que tenga que cumplirse para habilitar estos botones?
Hola Verónica, buen día!
Le hago una consulta, en qué versión de tercer dígito de 3.22 se encuentran?
Los botones se visualizan en la operación de Aceptar Trámites de Certificación filtrando para los Trámites que se encuentran en Estado: Pendiente.
Ustedes al indicar ese estado de trámite, los botones no les aparecen?
Quedamos atentos.
Hola Verónica, buenas tardes!
Están utilizando algún usuario con perfil de datos o perfil funcional limitado?
Envíenos captura (ocultando la información sensible) y los logs.
Lo probé con el usuario toba, que es el que utilizo y tampoco aparece… Aclaro que nosotros no estamos usando SUDOCU, porque vi que en el código de la operación llamaba a alguna función de SUDOCU.
Lo único que aparece es un notice: [Tue May 06 11:19:54.215903 2025] [php7:notice] [pid 436440:tid 436440] [client 192.168.30.1:50455] PHP Notice: Undefined index: estado_requisitos in /usr/local/proyectos/guarani/php/operaciones/egresados/actualizaciones/aceptar_tramites_certificacion/ci_nav_aceptar_tramites_certificacion.php on line 49
Pudieron ver este tema? Se puede utilizar la operación de Actualización de Trámites de Certificación en lugar de esta como se venía usando hasta la 3.21?
No tengo personalizaciones en Egresos, los registros están en estado_requisitos = ‘P’, por eso aparecen en esa pantalla, sólo no aparecen los botones y sólo muestra el notice ese que envié en el post anterior.
Buenísimo, cuando tengan los logs en modo debug por favor envíenlos así vemos qué puede estar pasando.
Te hago un par de consultas más para tener más info:
Están utilizando algún usuario con restricción funcional o les pasa con todos los usuarios?
Les sucede con todos los trámites o sólo en casos concretos?
Si van a “Administrar Requisitos de una Persona” seleccionando al alumno de uno de estos trámites, cómo ven el estado de los requisitos? Podrían enviarnos una captura?
Las solicitudes de egreso las realiza el propio alumno desde autogestión?
Estuvimos haciendo pruebas replicando lo más posible el escenario pero no pudimos reproducir el error.
Si no hay requisitos de egreso definidos el trámite queda directamente en Estado = Aceptado (en este caso no se muestran los botones porque el trámite ya está aceptado).
Si hay requisitos de egreso definidos el trámite queda en Estado = Pendiente (en este caso se muestran correctamente los botones).
Te hacemos una consulta, en qué versión de tercer dígito de la 3.22 se encuentran?
Anteriormente se encontraban en una versión anterior a la 3.22?
Habría que ver si la base fue actualizada correctamente, ya que la columna “estado_requisitos” se agregó por base en los diferenciales de 3.22.0.
Por favor pásennos los resultados de la siguiente consulta:
SELECT * FROM negocio.app_versiones_base;
Con eso vamos a poder ver si se aplicaron correctamente los diferenciales.
Ya encontré el problema, era una personalización que había quedado desactualizada (y que no se usaba). Ya se ven todos los botones.
Respecto al tema de los diferenciales, recomendás correrlos y pasar a la versión 3.22.1?
Que bueno que pudieron encontrar la raíz del problema.
Nosotros habíamos descartado que fuera una personalización por lo que habían indicado en este mensaje:
Hola Martín.
No tengo personalizaciones en Egresos, los registros están en estado_requisitos = ‘P’, por eso aparecen en esa pantalla, sólo no aparecen los botones y sólo muestra el notice ese que envié en el post anterior.
Por eso estábamos analizando el tema de los diferenciales.
Pero en el resultado de la consulta que nos enviás se ve que no hay diferenciales, es decir que no se trata de una base actualizada desde una versión anterior sino que se trata de un despliegue realizado directamente en 3.22, puede ser?
En ese caso no es necesario correr los diferenciales.
Sí, no recordaba haber personalizado esa función, pero sí… no podía ser tan complicado… Tengo tanto personalizado… je
Sí, es correcto, instalamos directamente la 3.22.0.