problemas con requisitos - correlativas de cursado

Hola

Por alguna razón que se desconoce, el control de correlativas de cursada dejó de funcionar.
Despues de jugar un rato con los requisitos y la inscripción del alumno, empezó a andar de nuevo (justo despues que lo reporté al siu).
Envio adjunto los logs del sistema de desarrollo involucrados, para ver si me pueden dar una mano en determinar porque dejó de funcionar.
Cabe acotar que la máquina de desarrollo es una maquina virtual y se reinició algunas veces, con lo cual el cache se debería haber actualizado.

No es la primera vez que ocurre esto y me gustaria saber que puede haber ocurrido.

En alguna respuesta dada anteriormente, salía que con cambiar un requisito nuevamente se arreglaba todo.

Levantaré la base de datos nuevamente para ver si se puede reproducir todo
Cualquier idea sería buena…
Gracias

Emilio


problema_requisitos.zip (1.3 MB)

Hola Emilio,

Tendrá que ver con el aplanado? En el momento en que no se ejecutaba el control de correlativas verificaste en el reporte “REQUISITOS » REPORTE DE REQUISITOS POR PROPUESTA” si estaba asociado al plan?

Saludos, Florencia.

Emilio, respondo dudas respecto a las tablas involucradas en el esquema de configuración de requisitos:
Adjunto imagen del modelo de datos.
sga_requisitos_grupos = Registra las diferentes combinaciones de requisitos para una accion (Examenes / Cursadas / Equivalencias / …)
para una entidad o subtipo de entidad determinada.
Aqui se va a registrar el dato “entidad_subtipo” o el dato “entidad”

Ejemplo 1:
Para la accion “Cursadas” necesitan registrar requisitos diferentes por tipo de propuesta, por ejemplo para Grado y para Posgrado entonces en esta tabla habrá dos registros.
En este caso se va a tener dos registros con el campo “subtipo_entidad” que corresponde a cada uno de los subtipos de tipos de propuestas.

  1. Grado → entidad_subtipo = 200
  2. Posgrado → entidad_subtipo = 202

Para corroborar estos subtipos de entidades:
select * from sga_g3entidades_subtipos where entidad_subtipo in (200,202);

Ejemplo 2:
Para la accion “Cursadas” necesitan registrar requisitos diferentes para algunas Responsables Academicas, por ejemplo
para “Facultad de Filosofía y Humanidades”, “Facultad de Cs. Sociales” y “Facultad de Ingeniería”.
En este caso se va a tener un registro por cada una de estas responsalbes academicas con el dato “entidad” que corresponde a cada responsable academica.

  1. Facultad de Filosofía y Humanidades → entidad = 20304
  2. Facultad de Cs. Sociales → entidad = 21050
  3. Facultad de Ingeniería → entidad = 3025

Para corroborar:
select * from sga_responsables_academicas WHERE entidad IN (20304,21050,3025);

sga_requisitos_x_accion = Para cada grupo se registran aqui los requisitos que se van a evaluar a cada alumno.
Aqui se registra un requisito (requisito + regla + parametros → Tener x actividades aprobadas | 100 | 1) o una entidad (entidad + estado → Ejemplo: Fisica I | Aprobada)

sga_requisitos_aplanado = Por cada grupo-requisito se define aqui las versiones de plan que son alcanzadas por esa definición.
Por cada alumno al que se le va a evaluar requisitos en alguna determinada acción, se ingresa a buscar requisitos a partir de esta tabla buscando lo que haya definido para su versión de plan de estudios. Luego de aqui a la tabla sga_requisitos_x_accion y sga_requisitos_conf_x_oper para filtrar solo los requisitos según la operación desde donde se estén controlando requisitos.

Para que la búsqueda de requisitos sea rápida al momento de tener que buscar que requisitos se le debe controlar a un alumno es que se ingresa por esta tabla por la version del plan de estudios del alumno.
y no tener que evaluar en que definición de requisitos por accion esta ese alumno y cuales son sus requisitos.
Por eso si la tabla sga_requisitos_aplanado esta mal definida, entonces no se le van a controlar los requisitos que deba controlarse al alumno en una operación.

Tambien adjunto una query que podras filtrar para un alumno o una version de plan de estudios y la acción y poder ver que requisitos estan configurados. La idea es agregar un reporte con esta consulta para poder rapidamente ver que requisitos estan configurados y activos par aun alumno y operación.

4


ConfiguraciondeRequisitos-ModelodeDatos.png

ConfiguraciondeRequisitos-ModelodeDatos.png

requisitos_configurados_x_accion.sql (1.43 KB)

En producción sigue fallando.
Adjunto las capturas de pantalla de lo que menciona Florencia

Se ejecutó el aplanado con el boton en el reporte, se modificó y volvió a modificar el estatus del requisito y se reinició tanto el apache como la máquina para evitar problemas de cache.

Creo que el problema sigue estando en la base. Veré con mas detalle lo que menciona Alejando.
Espero poder encontrar que pasó.


configuracion_requisitos_propuestas.JPG

configuracion_requisitos_propuestas.JPG_thumb.png

reporte_requisitos_propuestas.JPG

reporte_requisitos_propuestas.JPG_thumb.png

Hola,

El problema estaba en que la comisión no tenía asociada la instancia “Regularidad”, por lo tanto no ejecutaba el punto de control 4 (“Alumno Instancia Regular”) que es el que contiene el control de correlativas de cursada. Se asoció la instancia a la comisión y comenzó a controlar las correlativas de cursada.
Continuamos viendo el control de correlativas de aprobación que parece no ejecutarse siempre…

Saludos, Florencia.

8

Hola Flor

Si. Esa comisión no está muy bien armada.

Continuamos viendo el control de correlativas de aprobación que parece no ejecutarse siempre...

En la operación de inscripcion a cursadas no estaba habilitado el control de Correlativas de Aprobación, con lo cual fallaba.
Al cambiar eso, que no lo retuve en memoria, apareció el fallo de correlativas.

Por otro lado.
El modelo que muestra Alejandro, donde se carga?
La tabla sga_requisitos_aplanado, en que operación/es se actualiza?
Via codigo php o via triggers de base de datos?

Gracias por todo esto.

Emilio,

La tabla ‘sga_requisitos_aplanado’ se actualiza desde la operación “REQUISITOS » CONFIGURAR REQUISITOS POR ACCIÓN” :podés mirar el código PHP en <path proyecto Guaraní>/php/nucleo/requisitos/requisitos_x_accion/cn_pro_requisitos_x_accion_aplanado.php’'. Además se actualiza vía TRIGGER cada vez que se activa un plan-versión (‘tua_sga_planes_versiones’), se asocia una responsable académica a una propuesta (‘tia_sga_propuestas_ra’) o se desasocia una responsable académica a una propuesta (‘tdb_sga_propuestas_ra’).

Saludos, Florencia.

6