En la versión 1.15.4 agregaron la posibilidad de que el usuario cambie su contraseña.
Yo como administrador lo probé y funciono, pero el resto de los usuarios no pueden.
Mirando el tema de permisos desde la parte de administración de usuarios, los perfiles que yo cree para UNLP no tienen el tilde del pop-up activado para está funcionalidad, pero se lo tildo, guardo y no me lo guarda (sigue la cruz roja).
Hola Juan Pablo, te cuento que no pudimos reproducir el error en nuestros entornos de prueba así que te vamos a pedir el log de postgres al momento de realizar la modificación para que el equipo pueda identificar el problema y poder resolverlo.
Muchas gracias y saludos,
Ariel Zoia
Coordinador SIU-Mapuche/Pampa
Consorcio SIU
Tel/Fax+54+02293-432304 http://www.siu.edu.ar
Adjunto un log del postgres que se obtuvo al momento de guardar el perfil funcional agregando el pop-up para cambiar la contraseña, que es el que nos e guarda
Gracias Juan Pablo, lo revisamos y te contestamos la semana proxima.
Saludo Grande !
Ariel Zoia
Coordinador SIU-Mapuche/Pampa
Consorcio SIU
Tel/Fax+54+02293-432304 http://www.siu.edu.ar
Me sumo un poquito yo en la conversación. Estuvimos mirando el log que nos mandaron y haciendo otras pruebas y seguimos sin poder reproducir el problema, así que te cuento un poquito cómo es el funcionamiento para pedirte de realizar un par de pruebas.
La información de si un perfil puede acceder a un ítem (en este caso el popup de usuarios) se almacena en la tabla "apex_usuario_grupo_acc_item" que está en el esquema "toba_mapuche" de la base de datos. El popup de cambio de contraseña tiene el identificador "50000010". Por lo tanto, si el perfil Administrador ("admin") puede ver ese popup, debe haber una tupla en dicha tabla que tenga los valores ("admin", "50000010"). Para verificarlo, te pido por favor que corras la siguiente consulta contra la base de datos:
SELECT
usuario_grupo_acc, item
FROM
toba_mapuche.apex_usuario_grupo_acc_item
WHERE
proyecto = 'mapuche' AND
usuario_grupo_acc = 'admin' AND
item = '50000010'
Esta consulta debería responder con un registro ya que vos comentás que como administrador funciona bien. Siguiendo el mismo razonamiento, si cambiás el valor de “usuario_grupo_acc” en la segunda condición de la consulta por el identificador de algún perfil que hayas creado, la consulta debería responder sin ningún registro. Si este es el caso, te pido que trates de ejecutar una sentencia como la siguiente contra la base de datos (cambiando el valor “admin” correspondiente a la columna “usuario_grupo_acc” por el identificador del perfil al cual le querés habilitar el popup):
Si esta sentencia se ejecuta correctamente, se debería haber habilitado el popup. Te pido por favor que nos cuentes si siguiendo estos pasos se le habilita el popup al perfil o si se produce algún error, para lograr determinar por qué no está funcionando desde la interface del sistema.
Desde ya muchas gracias por tu colaboración para resolver el problema y quedamos a la espera de tus novedades para ver cómo continuar.
Ignacio,
hicimos la prueba desde el SQL directamente e inserto la tupla para otro perfil.
Ahora, desde la interfase de administración de perfiles del Toba, se ve el tilde en el pop-up.
El tema que si lo intentas sacar , a ver como se comporta, sucede lo mismo que al inicio, no lo saca. Guardas los cambios y al volver a ingresar esta tildado.
Por lo que veo el problema es que el sistema no registra bien los cambios que haces desde la interfase.
Hay alguna forma de activar logs PHP del toba y ver que hace al guardar los cambios? a ver si podemos tirarle mas pistas de donde se encuentra el problema.
Ignacio
les cuento que, por ahí no quedo antes bien expresado, ninguno de los tildes para lo de pop-ups me deja activar/desactivar.
Cualquier cambio que haga sobre el perfil funcional no me lo toma al guardar.
Por ejemplo, a un perfil le habilite la opción Adminstración->Autorizacion
y al ingresar con un usuario con ese perfil, no me lo toma
Gracias por la explicación. La buena noticia es que, al menos por la base, está funcionando... por lo que te hago otra consulta: las pruebas contra la base de datos las hiciste conectado con el mismo usuario de base de datos con el que se conecta el sistema? (el sugerido durante la instalación es "mapuche").
Otra prueba que se me ocurre ahora que podemos hacer (por si el problema está con los permisos en la conexión a la base de datos) es cambiar los parámetros "usuario" y "clave" en el archivo de conexión (<directorio_de_instalacion>/mapuche/instalacion/bases.ini) para que, en lugar de conectarse con el usuario del sistema, lo haga con el mismo usuario que con el que a vos te funcionaron las pruebas del mensaje anterior.
Con respecto a los logs de aplicación, te cuento que tenés las siguientes alternativas:
1. Mirar los logs del framework (SIU-Toba) durante la ejecución de esa operación. Estos logs se encuentran en <directorio_de_instalacion>/mapuche/instalacion/i__produccion/p__mapuche/logs/.
2. Mirar los logs de PHP. Éstos están guardados de acuerdo a cómo tengan configurado PHP en el servidor (php.ini). Si quieren mandar los mensajes por pantalla en vez de a un archivo (poniedo el parámetro "display_errors" en "On"), tenés que modificar también el archivo <directorio_de_instalacion>/mapuche/instalacion/instalacion.ini, cambiando el valor del parámetro "es_produccion" de "1" a "0", porque sino no se van a mostrar (una vez finalizadas las pruebas, te conviene volver a ponerlo en "1").
Espero que con esto podamos descubrir algo más. Te agradezco por tu ayuda y por tu paciencia. La verdad es que nos resulta muy difícil rastrear los errores cuando no podemos reproducirlos localmente.
Por favor contame cómo anduviste así vemos cómo seguimos…
Ese Suhosin creo que no siempre viene en el PHP , sino que depende de cada distro.
No se sobre que tienen montados sus ambientes de desarrollo y testing, quizás es por eso que nunca les salto.
Hasta donde vi, se debe indicar específicamente la instalación de este componente en PHP.
Si te sirve el dato, nuestros ambientes de desarrollo y pruebas están sobre Debian, que es el sistema operativo que recomienda el SIU para sus sistemas. Además tenemos puestos con Windows para asegurarnos que las cosas andan en ambas plataformas.
De todas maneras vamos a revisar un poco más sobre Suhosin y, llegado el caso, pondremos los controles correspondientes en el instalador/actualizador para evitar que se produzcan comportamientos no deseados como sucedió en este caso.