Hola a todos!!
stamos migrando Guarani 2, 2.9.4 a Guarani 3 con script de la versión 3.13.1.
Tenemos como advertencia final:
" Se crearon reglas relacionadas con las correlativas especiales. Debe programar las reglas de cada correlativa especial…"
Esto corresponde a 3 correlativas especiales, de planes de Guarani 2 vigentes.
Si es correcto.
Por cada “correlativa especial” en Guarani 2 se crea un requisito de tipo proceso en Guarani 3.
Pueden consultar estos requisitos con la siguiente consulta:
Select * from sga_requisitos where requisito_tipo = 6;
En la documentacion explica un ejemplo de como crear el archivo php que corresponde a la regla asociada al requisito de cada correlativa especial.
(Crear el archivo php de la regla)
Podes ver ejemplos de código de reglas usadas en requisitos en el siguiente path de la aplicación: \php\nucleo_lib\reglas
Si, queda igual que en Guarani 2, solo que ahora en Guarani 3 es un requisito (se encuentra en la tabla sga_requisitos) pero que les falta crear la regla que contendrá el código que esa correlativa especial tiene.
Igualmente vean cada caso de correlativa especial que es lo que se controlaba, porque quizás hoy en Guarani 3 puede ser que esa funcionalidad este ya contemplada en los diferentes requisitos de tipo proceso que pueden definirse como correlativa, o módulos del plan con sus diferentes formas de cumplimiento.
Por ejemplo si para una actividad de 3er año tenian una correlativa especial que indicaba que debian tener todas las actividades de 1er año aprobadas y todas las actividades de 2do año regularizadas y vigentes entonces pueden agregar dos requisitos que ya existen que contempla este caso:
Tener todas las actividades de x año aprobadas
Tener todas las actividades de x año regularizadas.
Donde al definir estos requisitos les solicitará que ingresen el año de cursada de la actividad que desean controlar.
Si, Ale ya controlamos eso. Pero para implementar con la funcionalidad existente, deberíamos versionar 27 Planes de estudio, contra codificar 3 requisitos.
En este momento no estamos en condiciones de versionar Planes, por lo que optamos por codificar los 3 requsitos y dejar el tema de re-estructurar Planes para más adelante.
Gracias.
ANA - UNNOBA
Si, como en todo esto hay que ver pro y contras, al ser solo 3 correlativas especiales nada mas, lo mas rápido es programar esas 3 correlativas especiales si es que se usan las mismas en todos esos planes de estudio.
Al finalizar la migración hay una consulta que lista los datos de los requisitos que se agregaron en la migración por cada correlativa especial que hay definido en los planes para saber cuales hay que desarrollar.
Ale:
No nos está tomando la codificación de la correlativa especial.
- Hicimos el php de la regla , que está migrada a sga_requisitos con requisito _tipo = 6.
- En sga_reglas en el campo php_clase el nombre es el mismo de la clase creada, y la regla es de tipo =3.
- Agregamos el requisito al punto de control 4.
¿La regla la agregaron en la carpeta correspondiente a personalizaciones?
¿Verificaste los logs para ver si se esta corriendo ese requisito?
Agregamos el requisito al punto de control 4.
[b]NO[/b] deben agregar estos requisitos que corresponden a correlativas especiales de G2 a ningún punto de control, ya que se corren a través del requisito [b]Correlativas de cursada[/b] o[b] Correlativas de aprobación[/b].
Ejemplo de correlativa:
Para cursar la actividad C el alumno debe tener:
- Aprobada la actividad A
- Aprobada la actividad B
- Requisito -> Correlativa especial actividad C. ([b]Correlativa Especial en Guarani 2 - Requisito en Guarani 3[/b])
- Requisito -> Tener presentado el Certificado de Salud
Estos dos últimos son correlativas de tipo requisito. No son actividades.
Si corres la siguiente consulta, devuelve los datos de esas correlativas?:
SELECT *
FROM vw_condiciones
WHERE condicion_tipo = '1' -- Correlativa para cursar
AND plan_version = <id plan version>
AND condicion_entidad = (SELECT entidad FROM sga_elementos WHERE elemento = <id elemento actividad que tiene la correlativa especial>);
Ale:
La regla la creamos en personalizacion/php/nucleo/_lib/reglas.
En los logs, no aparece el requisito o la regla. Agregamos un mensaje de debug en el método validar de la regla y tampoco lo escribe en el log.
Cómo funcionan los requisitos_tipo = 6, porque el resto de las reglas las tenemos de tipo = 5 si son de procceso.
Podes correr la consulta de esa vista y decirme que datos trae?
¿La clase php que implementa la regla, la definiste con el mismo nombre que esta detallado en la tabla sga_reglas que corresponde a ese requisito de correlativa especial?
En este caso la clase php debe tener el nombre sp846_n_4iyt.
Cuando se migra las correlativas especiales se crea el requisito y la regla. En la regla el nombre de la clase php se genera con el mismo nombre que el stored procedure que implementaba la correlativa especial en Guarani 2.
Lo unico que tenes que hacer es crear la clase php en tu esquema de personalizaciones con ese nombre de regla que ya quedo definido en la migración. No debes crear un nuevo nombre de regla.
Fijate para esa actividad que tiene como correlativa una correlativa especial.
Ale:
La vista devuelve 2 actividades y por último el requisito de la correlativa especial.
El problema es que en la máquina que estábamos desarrollando había errores con sga_requisitos_aplanados. Sacamos el control de correlatividades, lo volvimos a poner y ahora anduvo.
Ahora la ejecuta y estamos debagueando el php de la regla.
Gracias.
ANA - UNNOBA
Bien, entonces no era solo que no se corría esa correlativa especial, sino que ninguna correlativa se estaba controlando.
Estamos viendo de armar un proceso que actualice esa tabla de que relaciona requisitos a correr en cada operación con las versiones de planes de estudio. Ya que cada vez que se verifica que controles correr a un alumno en una operacion se hace la consulta en esa tabla que mencionaste a partir de la version del plan del alumno.
Por otro lado te comento que existe una operación en el sistema que esta oculta que permite probar los requisitos/reglas que vayan a crear, de esta forma primero lo pueden probar por esa operacion y luego cuando confirman que funciona correctamente entonces lo pueden probar desde las operaciones en donde agregaron ese requisito.
Vamos a ver si lo dejamos comentado en la wiki, En cuanto lo tengamos alli documentado les avisamos.
Ale:
Tenemos un problema el control de correlativas, regla_correltiva_de_cursada.php pierde la activIdad de origen cuando setea los parámetros de contexto antes de llamar al validar y no sabemos como recurperarla en la correlativa especial.
Si queres lo seguimos por Gds.
ANA - UNNOBA
Hola Ana, bueno ingresa una solicitud y envianos el log de cuando se corren los controles, para ver con que datos llega a este control de correlativas.
"Tenemos un problema el control de correlativas, regla_correltiva_de_cursada.php pierde la activIdad de origen cuando setea los parámetros de contexto antes de llamar al validar y no sabemos como recurperarla en la correlativa especial."
Esto se solucionará en la version 3.14.1. A la correlativa especial le llegará el dato de la actividad en la que se estan inscribiendo el alumno y en otro parámetro el dato de la actividad que corresponde a la correlativa (en el caso de correlativas que son actividades)
