Mi consulta tiene que ver con la operación verificar regularidad de los alumnos, para la versión 3.15. Según tengo entendido, al aplicar este control, verifica que el alumno tenga 2 finales aprobados en el año académico indicado. Por ejemplo, para ser regular en el año 2018, va a verificar que el alumno haya aprobado 2 asignaturas en el ciclo anterior (en nuestra facultad, seria entre 01/04/2017 hasta 28/02/2018). Por lo que pude ver, al consultar el proceso, esto lo logra aplicando ciertas reglas (las cuales se definen en una clase php específica para cada caso) las cuales se podrían personalizar según nuestras necesidades.
Ahora bien, consultando la operación, antes de determinar que regla aplicar, verifica en la tabla sga_perdidas_regularidad_causas, cuales causas existen para determinar la perdida de regularidad y con esta, que regla aplicar. El tema es que hay varias causas (por no decir todas) con la misma regla (nro 600), la cual es que el alumno haya aprobado 2 asignaturas en el periodo indicado.
Según logre entender (puedo estar equivocado), cuando se corre el proceso, consultas las causas de perdida de regularidad (sin verificar si están activas o no) y por cada causa, aplica la regla, por lo cual, en nuestro caso, aplica esta regla n veces (siendo n, la cantidad de causas) por cada alumno, lo cual demanda mucho tiempo y no le encuentro sentido. Además, no hay una operación en el sistema donde podamos activar y/o desactivar estas causas.
Cual seria la forma de proceder para solucionar esta situación? debo borrar las causas repetidas? o personalizar la regla para que traiga solamente una? Se tiene pensado en futuras versiones agregar una operación para activar y desactivar causas perdidas de regularidad?
Bueno, eso sería por ahora. Desde ya gracias por su tiempo.
Cuando se crea una base de datos de negocio desde cero (con el comando ‘guarani instalar’) se inserta en la tabla ‘sga_perdida_regularidad_causas’ un único registro:
INSERT INTO sga_perdida_regularidad_causas (causa_perdida_reg, nombre, descripcion, regla, estado) VALUES (1,'Dos actividades aprobadas', 'Tener al menos dos actividades aprobadas en el año académico', 600, 'A');
Intentaste borrar los registros que están de más en esa tabla? No debería haber problemas a menos que exista alguna fila en ‘sga_perdida_regularidad_det’ que haga referencia a la causa. Probá de borrarlas y cualquier inconveniente lo vemos.
Haciendo memoria, estas causas de perdida de regularidad se han creado producto de las migraciones realizadas desde la versión 2 al 3 (y a esto se debe, que tengamos varias que signifiquen lo mismo). Como vos decís, ya hay registros de perdidas regularidad con esas causas (las cuales necesitamos borrar ya que no tienen sentido). Igual, esto también tendremos que resolverlo con las otras facultades ya no somos la única en G3. Te adjunto una imagen de los datos de la tabla sga_perdida_regularidad_causas para que quede más claro nuestra situación.
Aún si se consideraran sólo las causas en estado “Activo” hay varias que refieren a la misma regla (600).
Por favor, adjuntá el resultado de ejecutar la siguiente consulta SQL sobre la BD de negocio de Guaraní:
SELECT DISTINCT sga_perdida_regularidad_det.causa_perdida_reg FROM sga_perdida_regularidad_det;
Como verás, coincide con la cantidad en sga_perdidas_regularidad_causas. Igualmente te aclaro que resultado quedó así porque se corrió el control de regularidad (versión 3.15) . Estos datos son de la base de pruebas y no la de producción. Los resultados de esta consulta en la base de producción, te los adjunto en la imagen, y en este servidor, se corrió el control de regularidad antes del cambio de versión (es decir, la 3.13). En este caso, es menor el número y solo aplico la de cantidad de materias aprobadas. Lo que a mi me llamó la atención, es que al ejecutar la operación verificar regularidad en la versión 3.15, trajo todas las causas existentes (que a su vez, aplica la misma regla) sin filtrar si estaba activa o no.
Te recuerdo que estas causas se han creado producto de la migración y no han sido cargadas a mano, así que una vez corregido los detalles de perdida regularidad, no habrá problemas de borrarlas.
Deberías entonces pasar a estado ‘B’ todas las causas excepto una. Esto necesariamente tendrás que hacerlo con una sentencia UPDATE sobre la base de datos.
Lo de recuperar sólo las causas activas cuando se verifica regularidad ya fue resuelto y saldrá en la versión 3.16. Te pido que creen una nueva solicitud en el Gestor de Solicitudes para pasarles el parche correspondiente.
