+ Enable access to guest user to use the PM_CASES.
+ Add PM_DASHBOARD permission to KPIs.
+ Add internal permission alias:
RBAC->userCanAccess()
* Verify if the user has a right over the permission. Ex.
* $rbac->userCanAccess("PM_CASES");
*
* Alias of permissions:
* PM_CASES has alias: PM_GUES_CASE
* This means that a role with PM_GUES_CASE could access like one with PM_CASES
* unless the permission is required as strict, like this:
* $rbac->userCanAccess("PM_CASES/strict");
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.
