Marcela, en versiones anteriores a 2.8.0 se usaba el concepto de intentos fallidos, donde en base a un parámetro del sistema ‘clave_max_cantidad_logueos_fallidos’, si el usuario que intentaba acceder a su perfil de autogestión lo hacia erróneamente la cantidad de veces que indica ese parámetro, se bloqueaba su perfil mediante el sp: sp_bloquearusuario.
Este stored procedure, setea aca_usuarios_ag.bloqueado = ‘S’ y aca_tipos_usuar_ag.estado = ‘B’, a los alumnos a ser bloqueados. Este ultimo campo, es el que figura en la operación admin0007.
Supongo que se debe tratar de casos de alumnos que fueron bloqueados en su momento por intentos fallidos al querer ingresar a su perfil.
Actualmente no se bloquea mas a los usuarios por intentos fallidos en el login, sino que se utiliza el captcha.
Marcela, es raro porque como indica Juliana a partir de la version 2.8.0 ya no se usa mas ese flag que indicaba si el usuario esta o no bloqueado. Revisaremos por las dudas si quedo alguna control respecto de ese dato, pero no deberia estar consultandose. En el modelo de datos se dejo por si alguien quisiera seguir usandolo…
Gracias Juliana y Alejandro por sus respuestas!
Ahora me queda claro y puedo explicarles a los Dptos de Alumnos porque están bloqueados esos alumnos.
Asi es Alejandro, no deja que ingresen al sistema hasta que no se le cambie el estado mediante la operación admin007.
Habría algún problema si le cambiamos el campo estado de la tabla aca_tipos_usuar_ag mediante SQL a todos esos alumnos?