Gente,
estamos teniendo problemas con la generación de claves de acceso para usuarios nuevos de 3W. Les comento que en nuestro caso, tenemos personalizado el sp_crear_alumno, ya que cuando se genera el legajo a un alumno, se genera el usuario de autogestion, con ciertos criterios propios. En ese procedimiento, se llama al sp_claveDefault que genera la clave, y que como siempre lo hacemos sobre nuestras personalizaciones, lo revisamos en la version 2.8.3 y NO TIENE CAMBIOS y realiza un sp_md5(vcPwdDefault)… esto es lo que hicimos, pero los usuarios NUEVOS NO PUEDEN INGRESAR…
Aclaro que estamos en version 2.8.3 y en la pagina principal 3W no esta nada acerca de generar clave para nuevos usuarios.
¿Que procedimiento sp de encriptacion debo usar? ¿Como soluciono este problema para los usuarios nuevos que se fueron generando y ninguno puede ingresar a 3W???
Espero sus respuestas.
Hola Marcela, si siguen usando la encriptación en MD5 no les va a funcionar el login porque desde la versión 2.8.1. se modificó el esquema de encriptación por uno mas eficiente.
Para ello, deberían ejecutar el comando ‘migrar_claves’
Julieta
nosotros ejecutamos el comando migrar_claves al migrar la BD, y los usuarios que ya teniamos generado, no tuvimos problemas.
El problema lo estamos teniendo con los nuevos usuarios que estamos generando para 3W
Saludos
Marcela, a partir de la versión 2.8.1, se dejó de setear contraseñas por defecto para los usuarios nuevos de autogestión y se comenzó a usar el circuito de recuperación de contraseña.
Los usuarios nuevos deberán recuperar contraseña ingresando al G3W2 y siguiendo el link ‘Olvidó su contraseña?’ que se encuentra debajo del formulario de login.
Como el mensaje de este link está poco claro, lo hemos mejorado para las versiones posteriores a 2.8.3, con el mensaje ‘’¿Olvidaste tu contraseña o sos usuario nuevo?‘’, pueden personalizarlo para la versión que tienen instalada, para que sea mas intuitivo para el usuario
Es el mensaje: ‘olvidaste_contrasenia’, del archivo: src/siu/mensajes/mensajes.es.php
El proceso de recuperación consiste en el envío de un link al e-mail del usuario que lo solicitó, donde se le permite modificar su clave.
Gente,
seguimos con problemas con esto de que los usuarios nuevos ingresen en Guarani 3W. Una vez que se cargan los datos de un ingresante desde Preinscripcion, y se le genera legajo en la carrera, supuestamente el alumno ingresa por el link "Olvidaste tu contraseña? " y puede generar su usuario de autogestion…
Estamos probando, y si ingresa DNI y captcha, y el mensaje es “El usuario no posee permisos para acceder al sistema”, y no puede seguir con la generacion de su usuario.
Necesito me indiquen que miramos para poder solucionar rapidamente este problema.
Otra cuestion, es que NO ESTAMOS ENCONTRANDO DOCUMENTACION acerca de estos cambios realizados desde la version 2.7.1 a la version 2.8.3. Es demasiado costoso para nosotros haber implementado una versión, y que aún no podamos conocer todos los cambios que se implementaron y que afectan nuestras personalizaciones…
Espero su respuesta respecto a ambos temas: generacion de nuevos usuarios y documentacion por versión acerca de los cambios.
Saludos
Marcela, siguiendo el link ‘Olvidaste tu contraseña…’ no se genera un usuario de autogestión, sino que sirve para asignar/modificar contraseñas de usuarios de autogestión que ya existan.
Es decir, para un usuario nuevo, deben darle el alta como usuario de autogestión, desde Gestión, con la operación admin007 - ABM de Usuarios de Autogestión. Allí le asignan los perfiles válidos: alumno, docente, administrativo, gerencial…, y luego el usuario podrá ir con su DNI y recuperar contraseña, para posteriormente poder loguearse con la ‘identificación’ también asignada en la operación admin007.
Resumen:
Dar de alta usuario de autogestión en Gestión, Operación admin007. Asignar perfiles válidos e identificación.
Proceso de recuperación de contraseña por el usuario. Se realiza con el DNI y debe tener registrado un e-mail válido.
Con respecto a la documentación, en el Portal hay una sección con la documentación de las versiones y las novedades por versión. Si estaban en 2.7 deberían ver las novedades de la versión 2.8. Con respecto a los cambios de 2.8 a 2.8.1/2.8.3, la única modificación es en el esquema de autenticación y visualización de ficha del alumno en perfil Gerencial (g3w2).
Hola,
a ver si entiendo bien, cada vez que se levanta una Preinscripcion de un alumno, luego Alumnado genera legajos a los alumnos ¿Y luego deben generar para cada alumno, el perfil asociado??? Uno por uno??? No se generan de manera automatica en la generacion del alumno?
Puede ser bastante engorrosa la generacion de usuarios, asignacion de perfiles,e tc.
De todas formas, estamos teniendo este problema de “El usuario no posee permisos para acceder al sistema” y le generamos un usuario, y le colocamos un perfil Alumno Activo…
De nuevo pregunto ¿donde buscamos el porque de este problema???
Saludos
Cuando se registra la inscripción a carrera, por trigger de insert de esa tabla si esa persona aun no tiene registro en la tabla de usuarios se da de alta el registro.
Para alguno de los alumnos que no pueda acceder que de ese error fijate lo siguiente:
Ese alumno tenga un registro en la tabla aca_usuarios_ag y uno o mas registros en aca_tipos_usuar_ag (mas de uno si fuera ademas un docente o usuario gerencial…)
Que el alumno tenga generado el legajo y este activo en esa carrera.
Que el usuario asociado a ese alumno tenga generada la clave. Ver que la clave sea algo similar a esto “$2a$10$1234569089cL0qEh39Ao0ukkAfi9YHSA.Y39N0gP9A2YFlNkAWGgu”
Marcela, se genera luego de la operación mat00001 el usuario de autogestión, pero en los casos que no deja ingresar al perfil, le falta agregar el tipo de usuario y setearlo en activo. Te adjunto una imagen. Corroborar tipos de usuario activos en: aca_tipos_usuar_ag
El alumno debe estar anotado en al menos una carrera.
Si querés hacer el seguimiento de la validación de los permisos para acceder al sistema, te digo los pasos que hace:
operaciones/acceso/controlador.php → chequea si el usuario tiene perfiles válidos. (en la parte de recupero de contraseña, función: accion__recuperar, donde llama a: persona::get_perfiles_validos($nro_ingreso)
modelo/entidades/persona.php → función: get_perfiles_validos, el estado del perfil debe ser Activo (ahí es donde influye el abm de usuarios de autogestión, imagen adjunta), luego… si es alumno: debe estar inscripto a alguna carrera (allí hace la validación utilizando la función: get_carreras_perfil)
modelo/entidades/persona.php → get_carreras_perfil, se fija si el alumno está anotado en alguna carrera… allí se accede al modelo:
modelo/datos/db/persona.php → función: carreras… trae datos para ese alumno?
Gente,
el alumno tiene ambas entradas…pero sigue dando el mismo error. Tiene entrada en aca_usuarios_ag, tiene una entrada con el perfil Alumno en aca_tipos_usuar_ag y es alumno activo de la carrera, pero el mensaje es “El usuario no tiene permisos para acceder al sistema”.
¿Donde mas miramos???
Saludos.
Gente,
otra cuestion, es que notamos que se generan los usuarios y claves por defecto, pero la clave generada NO tiene el peso que indican… sino que estan quedando claves como la siguiente “ea80892c7106b254db139824ac1016ce”
Nosotros nunca personalizamos el sp_md5, para que esto sea la diferencia… ¿Cual es el sp que coloca el peso?
Espero sus respuestas.
Marcela, se le coloca ese string en el campo ‘clave’ porque el mismo no puede ser nulo, por eso se sigue utilizando el sp: sp_claveDefault, y se le setea un string cualquiera.
La encriptación se hace únicamente desde PHP, o por el proceso de recuperación de password, o con el comando ‘migrar_claves’. No se realiza mediante SP.
Con respecto al mensaje de los permisos, deberías chequear qué pasa en ‘‘accion__recuperar’’ cuando realiza la siguiente validación:
//CHEQUEO CON NRO DE INGRESO SI TIENE PERFIL VÁLIDO
$perfiles_validos = persona::get_perfiles_validos($nro_ingreso);
if(count($perfiles_validos) == 0){
throw new error_guarani_usuario(kernel::traductor()->trans('login.errores.no_tiene_perfiles'));
}
Este es el único caso que no podés ingresar? Tiene alguna particularidad el alumno?
Gente,
no están pudiendo generar su clave todos los alumnos nuevos de la facultad, con todos da el mismo error de que el usuario no posee permisos para ingresar el sistema.
Estos son nuevos alumnos de nuestra Facultad.
Gente,
otra cuestion que noto, es que cada vez que se inscribe a carrera, se genera una entrada en aca_usuarios_ag pero NO en la tabla aca_tipos_usuar_ag.
Revisando un poco, veo que el sp en Informix sp_crearUsuarioAG, cuando entra por el ELSE (no existe el usuario de autogestion) solo realiza un INSERT en la tabla aca_usuarios_ag Y NO en la tabla aca_tipos_usuar_ag… ¿No debería realizar INSERT en ambas tablas?
No encuentro que la tabla aca_usuarios_ag tenga triggers de insert como para que lo haga en un triggers.
Espero su respuesta, como para modificar este sp.
Saludos
Gente,
ya descubrimos porque los alumnos NO podian ingresar, y daba que no tenia perfiles asignado.
El tema es que hay un parametro del sistema que es filtra_carrera_curso_ingreso que lo teniamos en valor = S, y como la carrera que tienen asociada los ingresantes es una carrera de ingreso… no les podia asignar perfil…
Eso por ese lado lo solucionamos cambiando el parametro del sistema: filtra_carrera_curso_ingreso = ‘N’.
Seguimos con el tema de que cuando se genera el usuario de AG, solo inserta en la tabla aca_usuarios_ag pero no en la tabla aca_tipos_usuar_ag.
¿Se modifico en versiones posteriores este problema en el sp_crearUsuarioAG?
Espero su respuesta para solucionar esto.
Saludos
Si, creo que falta el insert en esa tabla por la opcion del ELSE donde se crea el usuario de autogestion.
-- Para completar los registros faltantes corre lo siguiente:
SELECT unidad_academica, nro_inscripcion, tipo_usuar_inicial
FROM aca_usuarios_ag as a
WHERE NOT EXISTS (SELECT 1 FROM aca_tipos_usuar_ag as b WHERE where b.unidad_academica = a.unidad_academica AND a.nro_inscripcion = b.nro_inscripcion)
INTO temp_usuarios;
INSERT INTO aca_tipos_usuar_ag (unidad_academica, nro_inscripcion, tipo_usuario)
SELECT unidad_academica, nro_inscripcion, tipo_usuar_inicial
FROM temp_usuarios;
No se modificó en versiones posteriores. Veremos de incluirlo en la versión 2.9.1
Gracias,
modifique el sp y ahora funciona OK,
Nosotros estamos en version 2.8.3, pero estoy viendo que el SP tiene el mismo error en version 2.9.1.
Si les parece cargo un GDS para que realicen este cambio.
Saludos
Marcela, revisando nuevamente este tema, cuando se da de alta un registro en al tabla aca_usuarios_ag, inserta por trigger un registro en la tabla aca_tipos_usuar_ag. Con lo cual debo pensar que el trigger ti_usuarios_ag lo tienen deshabilitado o no lo tienen creado.
¿Podras verificarlo?
Esto paso porque agregue el cambio mencionado en el otro mensaje en el proceso de creación de usuario de autogestión y reportó el error de que ya existia el registro. Revisando el trigger de insert vi que ya estaba el INSERT en ese trigger.
