Mostrar Mensajes

Esta sección te permite ver todos los mensajes hechos por este usuario, recuerda que solo puedes ver los mensajes en áreas en donde tu tienes acceso.


Mensajes - amoyano

Páginas: [1] 2
1
Ahí paso el archivo  modificado.. le falta pulir y sacar cosas que se usaban en el archivo viejo, pero funciona.

La idea básicamente es, antes al perfil funcional se lo calculaba de esta forma, por ejemplo

de la siguiente consulta:

Código: [Seleccionar]
SELECT  *
FROM     tabla_sin_restricciones
JOIN        tabla_con_restricciones
                   ON  tabla_sin_restricciones.columna1 = tabla_con_restricciones.columna2
JOIN        tabla_con_restricciones as alias_tabla
                   ON tabla_con_restricciones .columna_join = alias_tabla.columna_join

Con el filtrado original obtendríamos una consulta similar a esta:

Código: [Seleccionar]
SELECT  *
FROM     tabla_sin_restricciones
JOIN        tabla_con_restricciones
                   ON  tabla_sin_restricciones.columna1 = tabla_con_restricciones.columna2 /* INICIO FILTRADO */  AND alias_tabla.columna_filtrado = condicion_filtrado /* FIN FILTRADO */
JOIN        tabla_con_restricciones as alias_tabla ON tabla_con_restricciones .columna_join = alias_tabla.columna_join
                   ON tabla_con_restriccion_filtrado .columna_join = alias_tabla.columna_join

Dando el error que alias_tabla no existe. Con el parche, la consulta quedaría de esta forma:

Código: [Seleccionar]
/* INICIO FILTRADO */
WITH tabla_con_restriccion_filtrado as (
    SELECT * FROM tabla_con_restricciones WHERE columna_filtrado = condicion_filtrado
)
/* FIN FILTRADO */
SELECT  *
FROM     tabla_sin_restricciones
JOIN        tabla_con_restriccion_filtrado
                   ON  tabla_sin_restricciones.columna1 = tabla_con_restriccion_filtrado.columna2
JOIN        tabla_con_restriccion_filtrado as alias_tabla
                   ON tabla_con_restriccion_filtrado .columna_join = alias_tabla.columna_join

Es decir, se crea un WITH antes del select, y se reemplazan todas las ocurrencias de la tabla filtrada dentro de la consulta.

Saludos.

Pd: Tuve que modificar el nombre del archivo y agregar la extensión .txt para que me deje subirlo

2
Hola Florencia,

Nosotros también tuvimos este problema. El error en realidad no está en Guaraní, sino que es más grave, ya que está en la forma en que Toba aplica los perfiles de datos. Potencialemnte este error puede estar presente en todas las consultas en donde se aplican perfiles de datos, tanto en las nativas de Guaraní como en las personalizadas.

El problema radica en que Toba no soporta que una tabla trigger aparezca más de una vez en una consulta. En este caso en particular el problema está en la tabla sga_planes, que aparece 2 veces, la primera vez sin alias y la segunda con el alias p_insc. A demás, el filtrado del perfil de datos sólo aplica a la primera tabla y no a la segunda.

Yo resolví el problema aplicando un parche al archivo vendor/siu-toba/framework/php/nucleo/lib/toba_perfil_datos.php y me gustaría poder compartirlo con la comunidad.

¿Cómo podría hacerlo?

Saludos.


3
Técnicos / Vinculación Aula Virtual con responsable académica
« on: Octubre 28, 2019, 01:25:48 pm »
Buenos días, actualmente estamos probando la versión 3.17.0 de Guaraní, y nos surgió la siguiente duda.

Actualmente en el IUA las responsables académicas tiene varias aulas virtuales cada una, pero vemos que a la hora de configurar los servidores de moodle, si la responsable académica ya fué asignada en otra aula virtual, ya no aparece disponible para la selección..

¿No sería mejor tener un combo para elegir un aula virtual disponible a la hora de configurar la comisión, o a la hora de generar las aulas masivamente?..

Se podría dejar la asignación de responsables académicas a la hora de configurar el servidor, para que la lista en el combo ya esté filtrada, pero yo no pondría tal restricción.

Saludos.

4
Técnicos / Re:Hooks
« on: Abril 13, 2016, 12:52:26 pm »
A las reglas no nos hizo falta agragarlas al core. Las pusimos dentro de personalizaciones/php/nucleo/_lib/reglas, pero tuvimos que agregar las referencias a las clases en personalizacones/php/guarani_autoload_clases_nuevas.php

La forma menos conflictiva con las actualizaciones que se me ocurre es en donde necesites que se realice un control, podrías personalizar la función y forzar el control, es decir, por ejemplo si supieramos que el momento en que una inscripción se acepta es en la función guardar() de la clase ci_inscripcion.php, y al requisito lo pegamos en el punto de control  alumno_operacion, podríamos hacer lo siguiente:

class ci_inscripciones_pers extends ci_inscripciones {

    function guardar() {
        //Ejecutamos guardar de la clase padre
        parent::guardar();

       $ptos_control_a_validar = array(guarani_punto_de_control::alumno_operacion);
   $params = array('alumno'      => $datos_alumno['alumno'],
                  'persona'      => $datos_alumno['persona'],   
                  'plan_version'   => $datos_alumno['plan_version'],   
                  'fecha'         => guarani_fecha::get_hoy(),
                  'propuesta'      => $datos_alumno['propuesta']);

        $retorno = guarani::validador_puntos_de_control($pto_control_a_validar, $params)->controlar();

    }
}   

Esto valdría la pena sólo si el requisito se implementa en varios lugares... si sólo se hace en ese punto, no se si sería mejos directamente hacer una llamada a una api y listo.

Saludos.

5
Técnicos / Re:Hooks
« on: Abril 13, 2016, 11:40:13 am »
Hola Pablo, nosotros tuvimos un problema similar, y lo solucionamos creando reglas ( http://documentacion.siu.edu.ar/wiki/SIU-Guarani/Version3.11.0/personalizaciones/requisito_proceso).

Con estas reglas generamos requisitos (Requisitos->Administrar Requisitos), y a dichos requisitos los configuramos para diferentes puntos de control. Hay que fijarse en el código de la operación para ver que punto de control se controla en un momento dado, para configurar los requisitos adecuadamente.

En nuestro caso, por ejemplo, para el control de pagos en inscripción a examen, el requisito simplemente llama a una api de un sistema externo, que le devuelve el resultado si el alumno está habilitado a inscribirse en un examen o no.

Espero haber sido de ayuda.

Saludos.

6
Usuarios / Re:TESIS
« on: Septiembre 25, 2015, 01:10:01 pm »
El circuito de tesis no anda, por un bug del archivo operaciones/tesis/administrar/ci_edi_tesis.php en la línea 123 para la versión 3.10.0, y en la línea 131 para la versión 3.10.3, en donde dice:

$datos_accion = toba::consulta_php('co_circuitos_tramite')->get_datos_estado_final($accion);

lo tuve que cambiar por las siguientes 3 líneas para que ande:

$estado = $this->dep('formulario')->ef('estado_actual')->get_estado();
$datos_accion = toba::consulta_php('co_circuitos_tramite')->get_estado_final_por_circuito_estado_accion($circuito, $estado, $accion);
$datos_accion[0]['estado_final_nombre'] = $datos_accion[0]['nombre'];

Es decir, trataban de buscar los datos del estado final, y en vez de pasarle un id de estado, le pasan un id de acción!.. obviamente, el estado final de la transición da cualquier cosa.

Ya hice un GDS al respecto.

Saludos.

7
Usuarios / Re:TESIS
« on: Septiembre 25, 2015, 01:07:42 pm »
El circuito de tesis no anda, por un bug del archivo operaciones/tesis/administrar/ci_edi_tesis.php en la línea 123 para la versión 3.10.0, y en la línea 131 para la versión 3.10.3, en donde dice:

$datos_accion = toba::consulta_php('co_circuitos_tramite')->get_datos_estado_final($accion);

lo tuve que cambiar por las siguientes 3 líneas para que ande:

$estado = $this->dep('formulario')->ef('estado_actual')->get_estado();
$datos_accion = toba::consulta_php('co_circuitos_tramite')->get_estado_final_por_circuito_estado_accion($circuito, $estado, $accion);
$datos_accion[0]['estado_final_nombre'] = $datos_accion[0]['nombre'];

Es decir, trataban de buscar los datos del estado final, y en vez de pasarle un id de estado, le pasan un id de acción!.. obviamente, el estado final de la transición da cualquier cosa.

Ya hice un GDS al respecto.

Saludos.

8
Técnicos / Re:Control de Pagos
« on: Diciembre 05, 2014, 10:20:26 am »
Hola Ale, ayer no pude ver nada de este tema.

Gracias por mencionar esa regla, voy a probarla antes de seguir con otra cosa.

Otra pregunta relacionada.. como puedo hacer para saber que puntos de control podría ejecutar una operación?..

Por ejemplo, después de esto, necesitaría hacer otro requisito de tipo proceso en donde si un alumno se inscribe a cursada asocia automáticamente al mismo a un aula virtual, dependiendo de la comisión en la cual se inscribe.. es decir, que necesito el alumno y la comisión como parámetro.

Otro caso sería cuando un alumno se inscribe exitosamente a propuesta (despues del control de pago), yo necesito un requisito de tipo proceso para informar al sistema de pagos que tiene que empezar a devengar cuotas por esa propuesta.. es decir que necesito el alumno y la propuesta como parámetro.

En estos dos ejemplos el punto de control 2 no me serviría, ya que sólo me devuelve alumno y fecha.

Habría forma de saber para una operación cuales son los parámetros de los puntos de control que puedo obtener?
Se puede configurar para cada operación que puntos de control revisar, o esta harcodeado en php?

Saludos.

9
Técnicos / Re:Control de Pagos
« on: Diciembre 03, 2014, 03:57:08 pm »
En el menú de administración de requisitos (no el de requisitos por operación, ni el de acción) pude configurarle el punto de control 4 y 6... y viendo ahora el contenido de esa tabla, la asociación ya estaba hecha.

Le configuré el 4 porque en los logs  aparece la siguiente frase cuando se ejecuta la inscripción a cursada "Controles del Punto de control 4 = array ()"..

Saludos.

10
Técnicos / Re:Control de Pagos
« on: Diciembre 03, 2014, 02:58:02 pm »
Hola Ale,

La regla nunca se ejecuta. En el caso de prueba que hice, asocié la regla a la acción cursada (accion 1) en la tabla sga_requisitos_validos (con lo cual, sospecho se debería ejectutar en todas las operaciones relacionadas a cursadas).

Cuando voy a configurar requisitos por acción no me aparece ningún requisito para seleccionar.

Saludos.

11
Técnicos / Re:Control de Pagos
« on: Diciembre 03, 2014, 01:27:28 pm »
Perdón, me faltó agregar que la versión de Guaraní en la que estoy probando es la 3.9.0 y pruebo desde la interfaz administrativa.

Saludos.

12
Técnicos / Control de Pagos
« on: Diciembre 03, 2014, 01:22:06 pm »
Hola a todos,

Estoy tratando de implementar un control de pagos en todas las operaciones relacionadas con inscripción a propuesta, reinscripción a propuesta, inscripción en examen e inscripción a cursada.

Hasta ahora como prueba me creé una regla que a la hora de validar siempre devuelve false (return $this->resultado_final(false);), y seguí los pasos descriptos en https://repositorio.siu.edu.ar/trac/Portal-G3/wiki/NotasTecnicas/requisito_proceso, es decir, que también agregué el requisito de tipo proceso y lo asocié con la acción de cursada en la tabla sga_requisitos_validos.. incluso, desde guaraní le asocié varios puntos de control.

Hasta ahora en todas las pruebas realizadas, permite la inscripción sin restricciones.

Traté de administrar requisitos por operación, y requisitos por acción, pero no pude agregar requisitos.

¿Que me estaría faltando para poder controlar este requisito en las operaciones indicadas?

Saludos.

13
Técnicos / Re:Bug detectado en Preinscripción
« on: Septiembre 18, 2013, 02:52:44 pm »
Muchas Gracias.

Saludos.

Agustín:

Amplío la respuesta anterior y te paso la actualización completa de longitudes de campos para esa tabla:

ALTER TABLE sga_unidades_acad ALTER COLUMN nombre TYPE VARCHAR(255);
ALTER TABLE sga_unidades_acad ALTER COLUMN calle TYPE VARCHAR(100);
ALTER TABLE sga_unidades_acad ALTER COLUMN numero TYPE VARCHAR(20);
ALTER TABLE sga_unidades_acad ALTER COLUMN codigo_postal TYPE VARCHAR(15);
ALTER TABLE sga_unidades_acad ALTER COLUMN fax TYPE VARCHAR(50);
ALTER TABLE sga_unidades_acad ALTER COLUMN te TYPE VARCHAR(50);
ALTER TABLE sga_unidades_acad ALTER COLUMN e_mail TYPE VARCHAR(100);
ALTER TABLE sga_unidades_acad ALTER COLUMN nombre_universidad TYPE VARCHAR(255);

Saludos,
Fernando

14
Técnicos / Bug detectado en Preinscripción
« on: Septiembre 18, 2013, 11:33:46 am »
En la base de datos de guarani 3, en la tabla sga_instituciones las columnas telefono y fax son de tipo character varying (50).

Los datos de esta tabla se exportan a la base de preinscripción a la tabla sga_unidades_acad. En esta tabla, las columnas anteriores corresponden a las columnas te y fax, las cuales son character varying (15).

El problema viene dado cuando el teléfono o fax ingresado en guarani excede los 15 caracteres, a la hora de exportar los datos a preinscripción. Postgres tira un error al tratar de hacer el insert en sga_unidades_acad, ya que excede la cantidad de caracteres permitidos.

Esto hace que los alumnos que quieran preinscribirse en una carrera que dependa de esta unidad académica no puedan hacerlo... es más, si sólo tenemos una unidad académica.. diréctamente los alumnos no se pueden preinscribir a ninguna carrera.

Saludos.

15
Soporte de Instalación / Re: recompilar datos
« on: Noviembre 11, 2008, 03:38:22 pm »
Muchas gracias a ambos por responder.

Voy a implementar la sugerencia de Ignacio, y no tengo dudas que va a funcionar bien. Espero haber podido colaborar en algo.

Saludos.

Agustín.

Páginas: [1] 2