El motivo de éste mensaje es solicitarles la incorporación de información del estudiante, que hoy únicamente es accesible desde “Administrar Personas”, en la Ficha del Alumno.
La última situación que nos surge revisando el área de egresos-títulos, con analíticos e info que necesitamos “levantar” de manera más ágil y que se vincula con el área de ingreso e inscripción a propuestas, nos remite al inconveniente de fondo que nos genera el no acceder a la información del estudiante desde la Ficha del Alumno, desde Guaraní.
La situación de ahora tiene que ver con la información cargada en “Estudios cursados” (de Administrar Personas). Hoy, en la Ficha, sólo muestra el secundario y si bien tenemos la info del estudio superior que le permitió inscribirse a la carrera de ciclo de complementación curricular en Administrar Personas (vía preinscripción o porque lo actualizamos nosotros desde gestión) no podemos verla ni levantarla desde la Ficha del Alumno. Esto tiene otras consecuencias, además de impedirnos agilizar la operatoria de nuestro circuito para egresos, que son también relevantes: por ejemplo, no poder acceder a reportes que serían de gran utilidad para evaluar las trayectorias de estudiantes en la Universidad, encontrar patrones comunes de comportamiento entre variables de ingresantes, etc.
La idea sería que esta información que tenemos en Administrar Personas, la muestre en la ficha del alumno y podamos así utilizarla en la gestión y trabajarla-analizarla. Las categorías serían entonces: estudios cursados, antecedentes laborales, financiamiento de estudios, situación familiar, tecnología, deportes, idiomas, entre otros.
Estos reportes justamente apuntan a aspectos distintos: uno refiere a los datos de la persona en sí y otro a los datos como alumno de una determinada carrera.
Desde el core de guaraní no se va a incorporar esos datos en la Ficha del Alumno ya que no son datos correspondientes a su desempeño en una carrera.
Pero si en su práctica necesitan tenerlos juntos pueden personalizarlo en su instalación para incorporarlos.
Lo que podemos incorporar en el core sí es una redirección entre las operaciones de “Administrar Personas” y “Ficha del Alumno” para poder moverse de una a otra con la persona/alumno ya seleccionada.
Tenemos una gran diferencia conceptual en la interpretación del desempeño en una carrera por parte del estudiante. En la UNQ estamos convencidos que el estudiante y su desempeño está marcado por múlltiples variables, que en muchos casos resultan condicionantes y/o determinantes en su tránsito en la propuesta.
En el contexto por demás conocido, voy a traer un ejemplo concreto y cotidiano para nosotros: tenemos en plena actividad un Programa de Trayectorias Estudiantiles que depende de la Secretaría Académica, que vía el Taller de Vida Universitaria, en la calidad de aspirante primero y en el primer cuatrimestre de la carrera acompañan a los estudiantes ingresantes. Ellos están solicitando de manera frecuente esta información que es dificilmente accesible y de construir para nosotros, de modo de generar reportes que les permitan a ellos saber QUIÉNES SON esos estudiantes. Saber la situación familiar o las condiciones tecnológicas, aporta información que se vincula de manera muy directa al desempeño de los ingresantes. Además, no podemos dar acceso a este tipo de usuarios a la operación de “Administrar personas” que sólo utilizan las áreas de ingreso.
Algo muy similar y más evidente ocurre con los estudios previos cursados: en muchos casos el título terciario que habilitó el ingreso a una carrera CCC es tan importante en el desempeño, que imaginate nos exigen a las Universidades que demos cuenta de ello en el título de egreso que le expediremos.
Desde hace varios años ya, hay una mirada más completa y compleja de la figura del estudiante en la Universidad, y me atrevería a decir en el sistema universitario en general. Pensemos en el SACAU sin ir más lejos…se trata de que la Universidad, y los equipos docentes efectuemos un sincericidio con nuestros estudiantes sobre el trabajo autónomo que demanda el curriculum. En ello, los otros aspectos de la persona-estudiante se vuelven a unir, no?
En fin, espero puedan reconsiderar esa concepción y decisión que dificulta la gestión cotidiana que hacemos en múltiples sentidos y áreas de la Universidad.
Saludos y a disposición para las aclaraciones necesarias, M
Como te comentaba, para que toda esa información se visualice directamente en la Ficha del Alumno sería necesario realizar una personalización, ya que no se trata de un cambio que esté previsto incorporar en el core del sistema.
Por otro lado, la operación “Administrar personas” está pensada exclusivamente para las áreas de ingreso, por lo que no podemos habilitar su acceso a otros tipos de usuarios.
¿Podrías contarme un poco más sobre el motivo por el cual no desean dar acceso a la información que necesitan? Así vemos si podemos encontrar una alternativa adecuada.
Hola Martín,
Antes que nada, gracias por reabrir el diálogo en tu última respuesta, para ver si podemos encontrar una alternativa adecuada. No respondí a la anterior porque no me pareció que había mucho más para decir de lo que ya había fundamentado.
La cuestión de la personalización no es algo que entiendo “sano” para la permanencia y actualización del módulo en la Universidad. En ésta dependencia tenemos muchos usuarios de gestión-administrativos de Guaraní y también el área técnica responsable de Guaraní y de otros módulos del SIU; por eso “conozco” los dos lados del mostrador. Entiendo que siempre hay una “negociación” entre lo que necesitan los usuarios y lo que analizan e implementan los técnicos, por suerte con criterio desde ambos lugares. El acumular personalizaciones no es algo que sea demasiado favorable, por ejemplo, al momento de actualizar a una nueva versión, no? De hecho estoy casi segura que si los técnicos pueden hacer esa personalización la van a hacer pero yo conozco-escucho después lo que cuesta avanzar a nuevas versiones de Guaraní, que son las que poseen soporte y recuperan las mejoras. Por ello, siempre tratamos de mantenernos en el más justo medio posible…te imaginarás la cantidad de pedidos que se reciben para que el sistema haga lo que cada persona-trabajador quiere-necesita.
Bueno, nada muy nuevo, que en distintas escalas y con diferentes actores supongo que será lo que les pasa a ustedes. Por eso fue mi explicación sobre la necesidad que tenemos de contar con esa información.
En cuanto a lo de dar acceso a “Administrar personas” a usuarios que necesitan reportes para gestionar y tomar decisiones, no está bien en nuestra lógica de acceso, uso y cuidado de la información del módulo. Se trata de un ABM que es responsabilidad de algunos usuarios, a los efectos de altas y modificaciones principalmente. Un Director de Carrera no puede tener acceso al mismo.
Volviendo a la solicitud realizada desde la UNQ, no puedo pensar ni un argumento en contra por parte de otras universidades, atendiendo a la reconceptualización y la búsqueda de mirar quiénes son nuestros estudiantes. No sé si haya alguna manera de que esto no se vea como información enchoclada en la ficha del alumno, pero que esté accesible desde allí en una misma operación, para que no tengamos que ir a diferentes operaciones para construir como rompecabezas a nuestro estudiante sería algo excelente.
En caso que no exista alternativa o posibilidad, creo que la vista de los estudios previos en la ficha del alumno es innegable en tanto como muestra hoy un secundario correspondería que muestre el terciario, ya que el título secundario es a la carrera de tronco único lo que el título terciario (estudios superiores) a un ciclo de complementación curricular (que es una carrera de grado también).
Sigo pensando, saludos y nuevamente gracias Martín por tu predisposición y tiempo!
Te comento los motivos por los que por el momento no está pensado incorporar dichos datos en la Ficha del Alumno.
Este reporte cuenta actualmente con 29 solapas, las cuales contienen una enorme cantidad de datos sobre la vida académica del alumno.
De acuerdo a tu pedido se deberían incorporar 7 solapas más, mezclando la información académica con la personal.
Si bien esto centralizaría la información en un único reporte, quedaría un volumen de información excesivamente grande que dificultaría el trabajo de los usuarios si el mismo no se encuentra bien organizado. Este tema ya fue trabajo con el equipo de UX y no vemos conveniente por este motivo incorporar estas solapas sino que por el momento se seguirá manteniendo por separada la información académica del alumno de su información personal.
Esto no descarta la posibilidad de que en un futuro se pueda incorporar toda la información de la persona (tanto personal, como académica, docente, datos de empleado, etc) en un único reporte. Pero el mismo debe ser elaborado de tal forma que permita al usuario navegar con facilidad entre la información, que sea intuitivo y que pueda ser configurado de acuerdo a los perfiles de datos y funcionales del usuario. Se trata de un trabajo de gran complejidad que en estos momentos no estamos en condiciones de encarar debido al gran volumen de solicitudes de alta prioridad.
Por lo tanto tomar el pedido sabiendo que no es algo que se pueda llegar a incorporar en el corto o mediano plazo no es correcto.
Por ello lo mejor es que veamos algunas alternativas para que puedan mejorar el trabajo de los usuarios con las herramientas que actualmente brinda el sistema. En este sentido les proponemos dos opciones:
Es cierto que “Administrar Personas” es un ABM que permite la escritura en base y que por lo tanto es lógico que no quieran dar acceso a la misma a determinados usuarios. Aún así, tengan en cuenta que a través de la configuración de perfiles funcionales pueden darle al usuario acceso a dicha operación únicamente con permisos de visualización y no de edición. Para ello se deben armar las restricciones funcionales pertinentes y asociarlas al perfil funcional del usuario. Para más detalles sobre cómo realizar esto les recomendamos que vean en el curso de Conceptos Iniciales la unidad referida a Perfiles Funcionales y de Datos; en la misma se muestra cómo realizar esta configuración.
Es cierto lo que comentás sobre las personalizaciones, que son elementos que muchas veces generan obstáculos a la hora de versionar ya que requieren mucho trabajo de revisión y adecuación. Pero tengamos en cuenta que no todas las personalizaciones implican el mismo grado de dificultad y complejidad de procesos. En este sentido las personalizaciones en reportes para incorporar nuevos datos suelen ser bastante comunes y sencillas de realizar. No suelen generar problemas a la hora de versionar ya que sólo implican mostrar datos guardados en determinadas tablas, y es muuy raro que en los versionados se modifiquen las tablas donde se guardan esos datos.
Esperamos que se entienda mejor el contexto por el cual no vemos conveniente sumar estas solapas de información en la Ficha del Alumno (al menos sin un análisis más profundo y un rearmado integral del reporte), y esperamos que alguna de estas alternativas les resulte de utilidad.
Lo que proponés es viable de hacer y ya lo teníamos en cuenta. Nuestro planteo tiene más que ver con que cuando identificamos un cambio que nos parece que suma al sistema en general, intentar que se incorpore al módulo nos parece lo ideal. Nos ha pasado de avanzar con personalizaciones que luego fueron desarrolladas en el core, implicando una duplicación de esfuerzos y posterior migración de una solución a otra.
El camino de la personalización intentamos dejarlo para las particularidades de nuestra institución, que no son pocas. Es verdad que los reportes no suman tanto trabajo, pero suman. Más allá de las posibles modificaciones en el modelo de datos (que las ha habido, el ej. más reciente es discapacidad), hay veces que implica actualizaciones de versión en PHP, PGSQL o Toba y pueden traer consigo deprecaciones que requieren revisión y adaptación. Como comentaba antes, ya contamos con un número considerable de personalizaciones que buscamos reducir, no incrementar.
Respecto a la restricción funcional para ¨Administrar personas¨, lo habíamos armado pero no nos convencía por lo desprolijo. Le estaríamos dando acceso a una operación ABM restringida y que, de hecho, no se puede restringir del todo ya que hay ítems que no se pueden bloquear.
Por todo lo expuesto, nos parecía que la solución natural era incorporar esa información a la ficha de la persona. Entiendo que es mucha información pero es la información relevante, uno no elige el corte de lo relevante. Estoy seguro que el equipo de UX podría encontrar una forma no demasiado costosa de organizar esa información en categorías para que sea más intuitivo y navegable.
Por último, quería comentarte que en la sección ¨Datos Personales y Censales¨ donde figura ¨Colegio¨ y ¨Titulo Secundario¨ está levantando el primer antecedente de estudio ordenado por título que tenga la persona, no necesariamente un secundario. No sé si se podrá agregar el listado de antecedentes o, en última instancia, corregir lo que hoy está levantando mal.
Con Ramiro tuve la suerte de poder hablar de esto durante el Taller.
Estuvimos analizando este tema de la Ficha del Alumno y estamos queriendo vehiculizar este pedido como una primera etapa dentro del armado de una suerte de legajo de la persona, que pueda concentrar toda su información tanto personal como académica.
Es algo que estamos analizando en profundidad para ver cómo es la mejor manera de encararlo.
Respecto a este tema:
Por último, quería comentarte que en la sección ¨Datos Personales y Censales¨ donde figura ¨Colegio¨ y ¨Titulo Secundario¨ está levantando el primer antecedente de estudio ordenado por título que tenga la persona, no necesariamente un secundario. No sé si se podrá agregar el listado de antecedentes o, en última instancia, corregir lo que hoy está levantando mal.
Yo ahí hice una prueba rápida y en mi ambiente funciona correctamente, me trae el colegio secundario por más que haya sido cargado luego de otros antecedentes de estudios.
Pero quiero hacer la prueba en la misma versión en la que les sucede a ustedes para ver si es algo que ya se solucionó en el medio.
La versión en la que les sucede es la 3.21.1?
Responderé de la primera parte del mensaje de Martín. Supongo que la propuesta apunta a distinguir la información de la persona por un lado y del alumno (persona inscripta en una propuesta=estudiante) por el otro. Me parece que puede ser una buena opción, siempre que se relacionen…se me hace dificil imaginarlo porque para nosotros terminan siendo condiciones indisociables, y supongo que por eso hablan de un legajo con ambas cosas. El alumno es primero persona y en función de varios aspectos de ésta condición, podemos “entender” su comportamiento como alumno-estudiante. Pero bueno, ya no voy a ahondar en esto!
En lo único que voy a insistir es en que puedan mostrar en la ficha del alumno la formación secundaria y también la terciaria. El pedido se termina relacionando con el GDS (de acuerdo al intercambio en el taller anual en MDQ), para la creación de los CCC (ciclos de complementación curricular) como un tipo de propuesta. El secundario es a la propuesta de grado o pregrado, lo que el terciario al CCC. En Araucano también se reconoce como un tipo de carrera al CCC.
Se realizaron pruebas en un ambiente 3.21.1 y no se detecta el error reportado.
Dentro de la sección de “Datos Personales y Censales” se muestra correctamente el colegio secundario del alumno, indistintamente de que este dato haya sido carga en forma posterior a otros estudios de nivel superior.
Es posible que se trate de un tema de ordenamiento por orden alfabético? Sería extraño, pero no habría que descartarlo. Si pueden envíennos los datos de los nombres de colegio, título y año de egreso que tiene cargado el alumno así vemos si es posible que venga por este lado el problema.
function get_estudios_persona($persona, $where=‘’)
{
$persona = toba::db()->quote($persona);
if ($where) {
$where = ’ AND ‘.$where.’ ';
}
$sql = "SELECT COALESCE(sga_colegios_secundarios.nombre, mdp_datos_estudios.colegio_otro, sga_instituciones.nombre_abreviado, mdp_datos_estudios.institucion_otra) as lugar_desc,
COALESCE(mdp_titulos.nombre, mdp_datos_estudios.titulo_otro) as titulo_desc,
mdp_orientacion_recibida.nombre as orientacion_recibida_desc,
mdp_datos_estudios.fecha_ingreso as fecha_ingreso,
mdp_datos_estudios.fecha_egreso as fecha_egreso,
mdp_titulos_tipos.nombre as titulo_nivel
FROM mdp_datos_estudios
LEFT JOIN mdp_titulos ON mdp_datos_estudios.titulo = mdp_titulos.titulo
LEFT JOIN mdp_titulos_tipos ON mdp_titulos_tipos.titulo_tipo = mdp_titulos.titulo_tipo
LEFT JOIN sga_instituciones ON mdp_datos_estudios.institucion = sga_instituciones.institucion
LEFT JOIN sga_colegios_secundarios ON mdp_datos_estudios.colegio = sga_colegios_secundarios.colegio
LEFT JOIN mdp_orientacion_recibida ON mdp_datos_estudios.orientacion_recibida = mdp_orientacion_recibida.orientacion_recibida
WHERE mdp_datos_estudios.persona = $persona
$where
ORDER BY titulo_desc
";
return guarani_db::consultar($sql);
}
Es por esto que ese campo puede mostrar, de forma aleatoria, datos de colegio secundario o estudios previos.
Lo vamos a analizar con el equipo técnico para ver cómo mejorarlo.
Si bien en nuestras pruebas no pudimos reproducir el error, como bien mencionás esto puede deberse a la forma en la que se arma el array y por ello hay veces en los que se muestra correctamente y momentos en que no.
También veo que en la versión 3.22.0 se incorporó un arreglo para que en las querys que recuperen colegios secundarios, filtrar las querys por campo nivel = S.
Si bien ese arreglo vino por otro lado, no por un problema en la Ficha del Alumno, es posible que esto también lo haya solucionado.
Lo analizamos con los técnicos y les comentamos lo que vemos.
El código de arriba es el de la 3.22.3, esa parte no tuvo cambios. Esta query en particular no es para recuperar secundarios si no para recuperar todos los datos de estudio de una persona. Se usa el método get_estudios_persona, que es el mismo que se utiliza en administrar personas, solo que allí se muestran todos los elementos del array y no el primero.
Justo ayer estuvimos con este tema y pudimos reproducir el error.
Efectivamente hay un bug en cómo se recupera el dato.
Ya creamos una issue para indicar el desarrollo de la solución.
Si pueden carguen un GDS así le asociamos el mismo.