Version compatible Kolla con Guarani 3.18.1

Estimados,

Tenemos instalada la version Guarani 3.18.1 con PHP 7.3. El tabla de correspondencias de compatibilidades para instalar kolla 4.3.2 supuestamente necesita PHP 7.1.x a 7.2.13.

Pueden funcionar ambas aplicaciones instaladas en el mismo servidor con PHP 7.3?

Saludos

Estimados.

Vimos la tabla de correspondencia, por lo que procedimos actualizar kolla 4.2.1 a 4.5. Pero no nos anduvo la misma, ya que se queda en blanco al querer acceder a kolla.

Notamos que hay varias cosas no aclaradas en guia de actualización:

  1. Los path de kolla nuevo y kolla antiguo deben ser diferentes? Versión a actualizar a cual se refieren?
  2. El directorio “aplicación” no figura en la versión que queda actualizada, si en la anterior. ¿Se copia el directorio?
  3. Deberían aclarar en la guia el error de las “clases repetidas”

Entendemos que hicimos todo bien, aún así, no nos funciona el ingreso a kolla, ni al rest, ni a kolla_usuarios. Se queda pantalla en blanco y lo peor que ni kolla, ni apache loguean nada.

Se restablecieron los links simbolicos que dice la guia y también el kolla.conf apunta al toba.conf para el apache.

Adjunto los log de instalacion.log e instalador.env

Gracias
Saludos!


instalador.env.txt (2.52 KB)

instalador.log.txt (52.3 KB)

Hola, siguiendo la solución en el foro https://foro.comunidad.siu.edu.ar/index.php?topic=22297.0, pueden avanzar con la actualización?

Saludos

Estimado. Buenas.

Ese caso lo ví y corroboré, pero no es nuestro caso, ambos parametros están seteados correctamente.
Esta instalación de kolla convive además con G3, 3W que funcionan sin problemas.

Ahí adjunté los logs de instalador, ¿Ves algo anómalo?

Saludos

Hola, buen día

Cuando intentan ingresar a Kolla desde el navegador si abren la consola del navegador, ¿hay algún mensaje o algún error?

Gracias, saludos!

Buenas tardes Diego,
Con respecto a tus consultas sobre la guia:

1. Los path de kolla nuevo y kolla antiguo deben ser diferentes? Versión a actualizar a cual se refieren?
Tienen que ser distintos, ya que posteriormente se realiza un enlace a ese directorio. La version a actualizar seria tu kolla "antiguo"
2. El directorio "aplicación" no figura en la versión que queda actualizada, si en la anterior. ¿Se copia el directorio?
Es correcta la nueva estructura, no debes copiar nada.
3. Deberían aclarar en la guia el error de las "clases repetidas"
Se esta resolviendo desde Toba.

Lo ideal seria que realiace una instalación desde cero, restaurando la base de datos.
En caso de no lograrlo, te pedimos que abras un GDS para obtener mayor información.

Saludos,

Chicos, Gracias por responder.

Mora: Desde el navedafor por consola, no genera ningún error, se queda en blanco, tal cual lo hace por browser

Paulo: Si hago un dump de la BD actual de kolla4.2, y luego la importo en una instalación de kolla4.5 de cero, ¿No dará problemas?
¿No cambió nada en la estructura de la BD de 4.2 a 4.5?

No podemos perder las encuestas y respuestas pasadas, por eso insitimos en actualizar y no una instalación de cero

Gracias

Diego,
A partir de una instalación de Kolla 4.2.1 con la base propia de esa versión -es decir sin las modificaciones que puedan haberse hecho en el intento de actualización que ya hicieron- sugerimos realizar una nueva actualización, empezando el proceso de cero.
La idea no es que empiecen a trabajar de cero con un Kolla nuevo perdiendo los datos que tienen, sino que puedan realizar una actualización “limpia” de errores de la instalación que ya tenían.

Estimado Paulo.

Ya probamos eso que comentas. Tanto en ambiente de Testing como luego en Producción.
Adjunté los los a este ticket, y vi que hubo otros inconvenientes similares.

¿Hay alguna forma de volvar los datos en una instalación nueva de kolla 4.5? Ya no encontramos que más realizar para que funcione.

Saludos

Hola Diego,
repasando este caso encontramos lo siguiente. En el archivo de configuración del instalador (instalador.env) se ven los alias definidos de esta manera:

###### CONFIG DE TOBA ######
...
TOBA_PROYECTO_DIR="/usr/local/proyectos/kolla45"
TOBA_INSTALACION_DIR="/usr/local/proyectos/kolla45/instalacion"
TOBA_ALIAS_PROYECTO="/proyectos/kolla"
#TOBA_ALIAS_NUCLEO="/alias_proyecto_koll"
TOBA_ALIAS_TOBA_USUARIOS="/proyectos/kolla_toba_usuarios"
...

Y en el archivo de log del proceso de actualización (instalador.log) se ve esto:

[2021-07-25 10:07:37] MAIN.INFO: [ PARAMETROS toba ] alias_nucleo_toba => '/toba_kolla'  
[2021-07-25 10:07:37] MAIN.INFO: [ PARAMETROS toba ] alias_toba_usuarios => '/proyectos/kolla_toba_usuarios'  
[2021-07-25 10:07:37] MAIN.INFO: [ PARAMETROS toba ] alias_proyecto => '/proyectos/kolla'  
[2021-07-25 10:07:37] MAIN.INFO: [ PARAMETROS toba ] instalar_usuarios => true  
[2021-07-25 10:07:37] MAIN.INFO: [ PARAMETROS toba ] instalar_editor => true  
[2021-07-25 10:07:37] MAIN.INFO: [ PARAMETROS toba ] instalar_referencia => true  
[2021-07-25 10:07:37] MAIN.INFO: [ PARAMETROS toba ] instalacion_dir => '/usr/local/proyectos/kolla45/instalacion'  
[2021-07-25 10:07:37] MAIN.INFO: [ PARAMETROS toba ] nombre_dir_instalacion => 'instalacion'  
[2021-07-25 10:07:37] MAIN.INFO: [ PARAMETROS toba ] proyecto_dir => '/usr/local/proyectos/kolla45'  

Hay varias cosas para señalar ahí. En primer lugar llama la atención que hay varias inconsistencias entre lo que se ve en el log con lo que indica el archivo env, no se a qué se puede deber, pero lo más importante es que “alias_nucleo_toba” parece haber tomado un valor por defecto “/toba_kolla” porque en el archivo de configuración está comentada esa línea y no se definió explícitamente el valor para el alias.
Deberían descomentar esa línea en el instalador.env y otorgar un alias para el nucleo de toba; y tener la precaución de que no coincida con el de la instalación anterior. Este cuidado de no sobreescribir los alias aplica por supuesto también para el proyecto kolla mismo.

Con respecto a esta consulta:

siempre que hay un cambio de primer o segundo dígito los cambios en la versión pueden implicar cambios en la base. No se puede usar una base de una versión con la instalación de otra versión diferente.

Repitan por favor la actualización de la 4.2.1 partiendo de la base restaurada al estado previo a la actualización teniendo en cuenta los comentarios sobre la configuración del entorno. Quedamos atentos, si surge algún mensaje de error avisanos y seguimos revisando. Puede ayudar habilitar un mayor detalle de los mensajes de error de php al menos hasta terminar el proceso de actualización, y luego los vuelven a deshabilitar.

Saludos
4

Muchas gracias por tomarte la molestia de la revisión Clara. Era lo que justamente necesitabamos.
Lo de la variable “alias_nucleo_toba” es buena observación y vamos a revisarlo, el tema del archivo " .env " lo dejamos tal cual como dice la documentación de actualización de Kolla.

Esa docu habría que agregarle mayor detalle o información de issues conocidos, porque está muy escueta y asi como está no funciona la actualización.
Probamos esto nuevamente y te comento

¡Gracias!

Clara: Buenas.

Podrá vos o alguien del SIU tomarse la molestia de tener una sessión con nosotros con pantalla compartida para ver si podemos resolver el problema?

Desde la institución nos cuesta creer que tengamos que no se pueda actualizar y tengamos que perder los datos anteriores de encuestas y respuestas.

Gracias

Buen día Diego,
danos de alta un GDS por favor, así te pedimos algunos datos por esa vía.
Saludos.
2

Hola Clara. Buenas.

Te cuento y para cualquier institución que tenga el mismo problema, pudimos solucionarlo de forma parcial, notando que para aquellas instalaciones de Kolla que no estén con usuario “postgres” (que es owner de todo), el usuario nominal para kolla debe tener rol “superuser” y tener “GRANT ALL” sobre la BD de kolla.
En nuestro caso pudimos resolverlo de esa manera, ya que vimos que no estaba pudiendo realizar un “ALTER SCHEMA toba_kolla RENAME TO toba_kolla_backup;”

Ahora tenemos otro problema, que cuando llamamdo a la api del rest → https://URLKOLLA/kolla/rest se redirige a “HTTP” en lugar de HTTPS.
Pudimos observar que en “instancia.ini” tenemos bien puesto el parametro → protocolo_url_post_form_externo=“https” … pero aún así no redirige a https cuando vas al rest.

¿Puede ser que cuando actualizas tengas que descomentar el parametro “TOBA_FORZAR_HTTPS” del archivo ?

Buen día Diego,
con respecto al protocolo HTTPS, si, al instalar (o actualizar) si van a usar HTTPS deben indicarlo descomentando ese parámetro y seteandolo en “on”, ya que el valor por defecto es “off”.
Pero no se preocupen, lo pueden configurar ahora descomentando la linea, definiendo el parámetro en on y luego ejecutan el siguiente comando:

./bin/instalador proyecto:reconfigurar toba

Una vez ejecutado esto, pueden verificar la correcta configuración revisando el archivo instalacion/web_server.ini y verificando que el contenido es

[server_config]
https = "on"

Saludos.
2

Hola Clara. Muchas gracias. Efectivamente solucionó el issue de https. Pero no terminamos más, ahora nos encontramos con el problema que desde 3w, no pueden ver las encuestas que estaban pendientes, porque les figura que “NO hay encuestas pendientes”, cuando sí habían antes de migrar.

En el Log veo lo siguiente en algunas. → “[2021-08-17 11:22:54] MAIN.WARNING: El registro de la institucion araucano con codigo ‘2684’ y nombre ‘Universidad SIGEN’ fue descartado durante el proceso de actualizacion de la base de datos. Por favor verifique la tabla arau_instituciones_backup.”

¿tiene algo que ver ese WARNING? ¿Sabes a que se puede deber la perdida de las encuentas pendientes en la actualización?

Gracias por la ayuda

Saludos

Hola Diego, la tabla arau_instituciones_backup no es una tabla que tengamos en el catálogo de la base.

ahora nos encontramos con el problema que desde 3w, no pueden ver las encuestas que estaban pendientes, porque les figura que "NO hay encuestas pendientes", cuando sí habían antes de migrar.
Podes ver el log de las consultas que se realizan luego del login en autogestion? Alli vas a ver la query sobre la tabla [b]gde_encuestas_pendientes[/b]. Toma esa query y fijate cual es la condición que hace que no recupere las encuestas que estan pendientes de contestar por el alumno.
¿tiene algo que ver ese WARNING?
Ese warning no tiene nada que ver con encuestas.
¿Sabes a que se puede deber la perdida de las encuentas pendientes en la actualización?
No debería haber perdidas de encuestas pendientes. Los registros deberian seguir estando en la base. Debe haber algun filtro o algun dato que haga que no se esten visualizando.

Hola Diego.

"[2021-08-17 11:22:54] MAIN.WARNING: El registro de la institucion araucano con codigo '2684' y nombre 'Universidad SIGEN' fue descartado durante el proceso de actualizacion de la base de datos. Por favor verifique la tabla arau_instituciones_backup."

Ese warning es solamente aclaratorio de que se actualizaron las tablas de Araucano y por si desean chequear dichos cambios, no es nada para preocuparse.

Por otro lado te consulto, solo actualizaron Kolla o también Guaraní? Realizaron la vinculación de la misma manera en la que estaba antes? Es decir mismos usuarios/contraseñas y sistema externo?

Saludos

Gracias Ambos.

Alejandro: Es como decis. Si le comento la parte de condición de CURRENT_DATE de la fecha, me trae las encuestas por SQL)

¿Hay Fix para esto? ¿Sabes indicarnos en que función o file puedo modificar esta query?

– SQL -----------------------------------------------------------------------

SELECT
p.hash as id, – id para luego marcar que fue contestado el formulario de encuestas.
p.formulario as formulario,
COALESCE(f.formulario_g2, p.formulario) as formulario_externo,
h.kolla_id_habilitacion as kolla_id_habilitacion,
h.kolla_password as kolla_password,
f.titulo as titulo_formulario,
COALESCE(cast(p.respuesta_g2 as text), p.hash) as id_externo, – id que se registra en Kolla si NO es anonima
h.tipo_relevamiento
FROM gde_encuestas_pendientes as p
JOIN gde_formularios as f ON (f.formulario = p.formulario)
JOIN gde_habilitaciones as h ON (h.habilitacion = f.habilitacion)
WHERE p.persona = ‘3284’
AND h.activo = ‘S’ – Habilitacion activa para contestar
AND p.fecha_respuesta IS NULL
AND CURRENT_DATE BETWEEN h.fecha_desde AND h.fecha_hasta
AND f.estado = ‘A’ – formulario activo
AND h.kolla_id_habilitacion IS NOT NULL
AND f.generado_en_kolla = ‘S’
AND h.encuestado = ‘A’

– DATOS ---------------------------------------------------------------------

ARRAY VACIO

Muchas Gracias

Diego entonces por lo que comentas esa habilitación ya no esta vigente, por eso no visualiza las encuestas pendientes de contestar a los alumnos.
En Kolla también ya venció esa/s habilitacion/es ?
¿Tienen registradas las mismas fechas de inicio y fin?

Fijate si podes modificar la fecha fin de la habilitacion a una fecha mayor a hoy, es decir hasta la fecha de finalización que hayan definido.