Buenas!, me pidieron personalizar el proceso de regularidad y ustedes por defecto tienen la regla de Dos actividades aprobadas, nosotros necesitaríamos Una actividad aprobada por lo menos en el año. Lo que hice es seguir la documentación: https://documentacion.siu.edu.ar/wiki/SIU-Guarani/Version3.18.0/personalizaciones/requisito_proceso, los archivos que hice son siguiendo la documentación y están puestos en las rutas correspondientes, los deje adjunto en el .rar y los .sql de regla y requisito fueron ejecutados obviamente en la base. ¿Me dirían que me estaría faltando hacer para que aparezca la nueva regla?
Te paso un hilo del foro donde se trato el mismo tema, y un link a la documentación donde menciona lo siguiente:
Para agregar nuevos requisitos o causas de pérdida de regularidad, deberá agregarse un registro por cada requisito en la tabla sga_perdida_regularidad_causas creando la regla correspondiente (sga_reglas) que tenga desarrollado el proceso que se refiere a dicho requisito. Como ejemplo se puede ver la regla 600 - Verifica que el alumno tenga aprobada dos actividades en un año académico que es el requisito que se entrega por defecto desde el SIU.
Luego por Sistema deberán configurar para que propuestas y ubicaciones se va a controlar ese requisito para evaluar la regularidad del alumno o la readmision en la propuesta. (Tabla sga_propuestas_regularidad)
Hola, consulta:
Cuando se ejecuta el control de regularidad de los alumnos, con las reglas que sean… es posible que se agregue un paso de selección de los alumnos que perderán la condición, para luego seleccionarlos y procesarlos? (de la misma forma que se filtran por ejemplo para inscripciones pendientes a actividades)
Además, si necesito controlar el último año que varía según la fecha de ingreso del alumno, o sea, si estoy controlando el año 2022, no debería analizar los que entraron en el segundo cuatrimestre porque aún les queda un cuatrimestre para aprobar, como debería hacerlo?
Cuando se ejecuta el control de regularidad de los alumnos, con las reglas que sean... es posible que se agregue un paso de selección de los alumnos que perderán la condición, para luego seleccionarlos y procesarlos?
Habría que evaluar como esta desarrollada la operación y si es posible incluir una opción mas al comienzo que indique si desea verificar y registrar perdida de regularidad o solo sea una verificación e informe que alumnos perderían la regularidad. Tambien tienen que ver si tienen readmisión automática y hasta cuantas veces permiten la readmisión automática.
Además, si necesito controlar el último año que varía según la fecha de ingreso del alumno, o sea, si estoy controlando el año 2022, no debería analizar los que entraron en el segundo cuatrimestre porque aún les queda un cuatrimestre para aprobar, como debería hacerlo?
Para esto, debiera agregarse un filtro mas que sea período de inscripción. Que en este caso evaluarias solo a los alumnos que ingresaron en el período de inscripción de comienzo de año.
Otra opcion es que el requisito a evaluar verifique si el alumno ingresó a comienzo de año o a mitad de año y en cada caso controle lo que deba controlar. O a los alumnos que ingresan a mitdad de año, evaluan su regularidad tambien a midad de año? Para los ingresantes del 2do cuatrimestre de 2022 los evaluan luego de los finales de Julio de 2023?
Buenas, seguí todos los pasos que me dijeron, la regla nueva de Una actividad aprobada, aparece, pero al seguir los mismos pasos cargando por ejemplo, la propuesta de Lic. en informatica, la default de dos actividades, carga perfecto, y la personalizada de una actividad, la barra del proceso queda en 0%.
Verificaron los logs específicos del proceso (los pueden encontrar en ‘<path proyecto Guaraní>/instalacion/i__desarrollo/p__guarani/logs/procesos_bk/’ dentro de una carpeta con el nombre de la operación y la fecha y hora de ejecución).
En los logs de comandos (‘<path proyecto Guaraní>/instalacion/logs_comandos/comandos,log’)?
Hola!, te adjunto los logs. El que me hizo ruido es el de log_ejecucion en pro_verificar_regularidad_alumno, que dice que no encuentra el parametro “fecha desde” pero en su clase nucleo, regla_nucleo. No entenderia como solucionarlo.
Cómo definieron la regla? Qué parámetros tiene? Pueden adjuntar las sentencias SQL que utilizaron para los cambios en la base de datos? También les pido los cambios en el código PHP porque no los veo commiteados en su nodo de colab…
No veo ningún problema con la regla personalizada.
El error “No se encuentra el parámetro: Fecha desde” se produce porque tienen definido el parámetro ‘fecha_desde’ en la regla ‘regla_regularidad_una_actividad_aprobada’ pero el mismo no está recibiendo un valor. Pueden chequear en la invocación a la validación de la regla (/usr/local/proyectos2/guarani/php/nucleo/matriculas/alumnos/vencimiento_regularidad/vencimiento_regularidad_nucleo.php, línea 76) por qué no hay valor en la variable $fecha_desde? Como está hoy la operación es un dato obligatorio en la primer pantalla de la operación “MATRÍCULA » REGULARIDAD » VERIFICAR REGULARIDAD DE LOS ALUMNOS”. Tienen eso también personalizado?
Hola, en el php creado regla_regularidad_una_actividad_aprobada puse un toba::logger()->debug(“DEBUG FECHA DESDE:”+$fecha_desde); pero no loguea el error en sistema.log, solo aparece lo siguiente:
-o-o-o-o-o-
Fecha: 05-04-2023 16:08:37
Operacion: Verificar regularidad de los alumnos
Usuario: toba
Version-PHP: 7.4.33
Servidor: localhost
URI: /guarani/3.20/aplicacion.php?ah=st642dc5d7c93548.18483069&ai=guarani||38000131&tcm=central&ai=guarani||38000131&ts=ajax&ajax-metodo=estado_proceso&ajax-modo=D&ajax-param=&tsd=guarani||38000741,
Referrer: http://localhost:3000/guarani/3.20/aplicacion.php?ah=st642dc5d51f4a12.77377850&ai=guarani%7C%7C38000131
Host: 172.17.0.1
==========
[DEBUG][guarani] PUNTO DE MONTAJE: se cargó exitosamente el autoload del punto de montaje proyecto
[DEBUG][guarani] PUNTO DE MONTAJE: se cargó exitosamente el autoload del punto de montaje personalizacion
[INFO][guarani] PUNTO MONTAJE: se cargó la clase extension_toba/guarani_sesion.php del punto de montaje proyecto. El path del mismo es /usr/local/proyectos2/guarani/php
[INFO][guarani] PUNTO MONTAJE: se cargó la clase extension_toba/autentificacion/guarani_pers_usuario.php del punto de montaje personalizacion. El path del mismo es /usr/local/proyectos2/guarani/personalizacion/php
[INFO][guarani] PUNTO MONTAJE: se cargó la clase extension_toba/guarani_fuente_datos.php del punto de montaje proyecto. El path del mismo es /usr/local/proyectos2/guarani/php
[DEBUG][guarani] SQL sin perfil de datos: SELECT trim(version_app) as version_actual
FROM app_versiones_base
ORDER BY id_conversion DESC
LIMIT 1
[DEBUG][toba] [SECCION] Iniciando componentes...
[INFO][guarani] PUNTO MONTAJE: se cargó la clase nucleo/matriculas/regularidad/cn_pro_verificar_regularidad_alumno.php del punto de montaje proyecto. El path del mismo es /usr/local/proyectos2/guarani/php
[INFO][guarani] PUNTO MONTAJE: se cargó la clase operaciones/matriculas/regularidad/ci_pro_verificar_regularidad_alumno.php del punto de montaje proyecto. El path del mismo es /usr/local/proyectos2/guarani/php
[DEBUG][toba] componente(14000032): Pantalla de eventos: 'seleccion'
[DEBUG][toba] [SECCION] Procesando eventos...
[DEBUG][toba] componente(14000032): [ inicializar_dependencias ]
array (
0 => 'ci_procesamiento',
)
[INFO][guarani] PUNTO MONTAJE: se cargó la clase operaciones/matriculas/regularidad/ci_nav_verificar_regularidad_alumno.php del punto de montaje proyecto. El path del mismo es /usr/local/proyectos2/guarani/php
[DEBUG][toba] componente(38000741): Pantalla de eventos: 'pant_resultados'
[DEBUG][toba] componente(38000741): [ inicializar_dependencias ]
array (
0 => 'form_totales',
)
[INFO][guarani] PUNTO MONTAJE: se cargó la clase operaciones/matriculas/regularidad/form_totales.php del punto de montaje proyecto. El path del mismo es /usr/local/proyectos2/guarani/php
[DEBUG][toba] [SECCION] Configurando dependencias para responder al servicio...
[DEBUG][toba] componente(14000032): Pantalla de servicio: ''
[INFO][toba] componente(14000032): [ callback ] 'conf__seleccion' no fue atrapado
[DEBUG][toba] componente(38000741): Pantalla de servicio: ''
[DEBUG][toba] componente(38000741): [ callback ] 'conf__pant_resultados'
[DEBUG][toba] componente(38000741): [ callback ] 'conf__form_totales'
[INFO][toba] componente(14000032): [ callback ] 'conf__ci_procesamiento' no fue atrapado
[DEBUG][toba] [SECCION] Respondiendo al servicio__ajax...
[DEBUG][guarani] [Respuesta AJAX] array (
'abortar' => false,
'mensajes' =>
array (
),
'progreso' => 9.0,
'error' => false,
)
Como está hoy la operación es un dato obligatorio en la primer pantalla de la operación "MATRÍCULA » REGULARIDAD » VERIFICAR REGULARIDAD DE LOS ALUMNOS". Tienen eso también personalizado?
Hola!, me fije y solamente tiene logueados unos guarani exportar, al parecer el comando de regularidad ni lo ejecuto, te lo dejo adjunto por si queres verlo.
El mensaje de debug no se va a llegar a generar en los logs del proceso porque falla antes, cuando setea los parámetros asociativos de la regla y se encuentra con que ‘fecha_desde’ es vacío. Eso es lo que quería que verifiques, en el método ‘get_requisitos_no_cumplidos’ de la clase ‘vencimiento_regularidad_nucleo’ (‘/usr/local/proyectos2/guarani/php/nucleo/matriculas/alumnos/vencimiento_regularidad/vencimiento_regularidad_nucleo.php’) por qué no llega una fecha desde válida si es un dato obligatorio en la interfaz.
Hola!, deje el debug en el archivo que me indicas pero siguen sin aparecer tanto en comandos.log como sistema.log:
/**
* Retorna un arreglo con los requisitos de regularidad no cumplidos por el alumno dado, de acuerdo a las
* causas de p�rdida de regularidad dadas y utilizando como par�metro para la validaci�n el a�o acad�mico y rango de fechas dado.
* @param array $alumno datos del alumno para el cual se verifican los requisitos
* @param array $causas_perdidas_regularidad causas por las cuales el alumno puede perder la regularidad
* @param int $anio_academico a�o utilizado para validar las reglas
* @param date $fecha_desde fecha desde utilizada para validar las reglas
* @param date $fecha_hasta fecha hasta utilizada para validar las reglas
* @return array arreglo con todas las causas de p�rdida de regularidad para las que el alumno no valida el requisito.
*/
static function get_requisitos_no_cumplidos($alumno, $causas_perdidas_regularidad, $anio_academico, $fecha_desde, $fecha_hasta)
{
$requisitos_no_cumplidos = array();
toba::logger()->debug("DEBUG FECHA DESDE:");
toba::logger()->debug($fecha_desde);
foreach ($causas_perdidas_regularidad as $causa) {
$regla = guarani::regla($causa['regla']);
// Par�metros de contexto de la regla.
$parametros_contexto = array();
$parametros_contexto['alumno'] = $alumno['alumno'];
$parametros_contexto['persona'] = $alumno['persona'];
$parametros_contexto['valor_parametro'] = guarani::parametros()->get_valor('mat_regularidad_alumno', array($alumno['propuesta']));
// Par�metros asociativos de la regla.
$parametros_asociativos = array();
$parametros_asociativos['anio'] = $anio_academico;
$parametros_asociativos['fecha_desde'] = $fecha_desde;
$parametros_asociativos['fecha_hasta'] = $fecha_hasta;
$regla->set_parametros_contexto($parametros_contexto);
$regla->set_parametros_asociativos($parametros_asociativos);
$valida = $regla->validar();
if (!$valida) {
$requisitos_no_cumplidos[] = array( 'causa_perdida_reg' => $causa['causa_perdida_reg'],
'descripcion' => $causa['descripcion']);
}
}
return $requisitos_no_cumplidos;
}