La información personal de un usuario Administrador se ve en modo view.
HOR-788
La información personal de un usuario Administrador se ve en modo view.
HOR-788
La información personal de un usuario Administrador se ve en modo view.
HOR-788
La información personal de un usuario Administrador se ve en modo view.
HOR-788
La información personal de un usuario Administrador se ve en modo view.
Issue:
Asignacion de un rol a usuarios tarda demasiado
Cause:
Los metodos Roles::getRoleUsers() y Roles::getAllUsers() no son optimos
Solution:
- Se a mejorado el metodo \ProcessMaker\BusinessModel\Role\User::getUsers() (Back-End)
- Se agrego el pager a los grids en ADMIN>Users>Roles>Users (Front-End)
HOR-474 "Asignacion de un rol a usuarios tarda demasiado " SOLVED
Issue:
Asignacion de un rol a usuarios tarda demasiado
Cause:
Los metodos Roles::getRoleUsers() y Roles::getAllUsers() no son optimos
Solution:
- Se a mejorado el metodo \ProcessMaker\BusinessModel\Role\User::getUsers() (Back-End)
- Se agrego el pager a los grids en ADMIN>Users>Roles>Users (Front-End)
HOR-474 "Asignacion de un rol a usuarios tarda demasiado " SOLVED
Issue:
Asignacion de un rol a usuarios tarda demasiado
Cause:
Los metodos Roles::getRoleUsers() y Roles::getAllUsers() no son optimos
Solution:
- Se a mejorado el metodo \ProcessMaker\BusinessModel\Role\User::getUsers() (Back-End)
- Se agrego el pager a los grids en ADMIN>Users>Roles>Users (Front-End)
> Code Isuue:
0018011: Security hole:REST endpoints for users,groups,departments & roles do not check if logged-in user has PM_USERS permission in role
> Solution:
Se agrega validacion en el siguiente Endpoint cuando se utiliza el servicio REST, el mismo mostrara un mensaje indicando
que el usuario no esta autorizado para realizar la accion.
- Cuando se cambiaba el estado de un rol a inactivo cual quier persona con ese rol podia seguir logueandose.
- Cuando se creaba un usuario y se le ponia en estado inactivo se podia loguear.
- Se agrega la validacion del estado del rol en el archivo RbacUsers.php en la funcion verifyLogin donde retorna "-6" si el rol esta como inactivo.
- Al crear un usuario se hacia una doble validacion para el estado, ahora solo se toma en cuenta la que esta en la class.rbac.php en la funcion createUser
- Cuando se cambiaba el estado de un rol a inactivo cual quier persona con ese rol podia seguir logueandose.
- Cuando se creaba un usuario y se le ponia en estado inactivo se podia loguear.
- Se agrega la validacion del estado del rol en el archivo RbacUsers.php en la funcion verifyLogin donde retorna "-6" si el rol esta como inactivo.
- al crear un usuario se hacia una doble validacion para el estado, ahora solo se toma en cuenta la que esta en la class.rbac.php en la funcion createUser
- Fields deprecated and wrong default filter for the ldap class
- Those parameters are not used, now it is only used the additional filter, with this field you can create the same filters or more complex filters.
Also, we've detected that the filter by default we are using the following condition: (objectCategory=person)
So, your filter is not working anymore, now we have been removed that condition to search in all objects and if you want to limit the objects on which searches can be done, you have to add your own filter.
- The permission PM_REPORTS cannot be removed because many projects already used (plugins made by projects), then the permision has changed to status inactive and in new installations will be hidden in the permision administrator module
- The ldap list was generated with an excessive size and the checkboxes
were not selected in the entire page.
- The Ldap list was optimized to generate it with the smallest size possible
- It was created a new template to improve the selection of the checkbox.
