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)
- Even if a user has an INACTIVE status, using the PMFCreateUser function, he/she is able to login to ProcessMaker.
- Problema resuelto, al crear un usuario con la funcion PMFCreateUser con tipo de estado "INACTIVE", el usuario se creara
como inactivo y se registrara en las bases de datos correspondientes y no podrácceder a ProccessMaker.
Disponible para la version 2.5.3 de ProcessMaker.
- No se realizaba la verificacion en la tabla PERMISSIONS de la base de datos RBAC al realizar upgrade.
- Se agrega la funcion verifyPermissions en la clase rbac.php la cual verifica los permisos, realizando los insert de los permisos que faltaran de acuerdo a la funcion loadPermissionAdmin, al realizar el upgrade.
- No se realizaba la verificacion en la tabla PERMISSIONS de la base de datos RBAC al realizar upgrade.
- Se agrega la funcion verifyPermissions en la clase rbac.php la cual verifica los permisos, realizando los insert de los permisos que faltaran de acuerdo a la funcion loadPermissionAdmin, al realizar el upgrade.
- Change the primary identifier samaccountname by other field
- Problem solved, User Identifier field can now be set to samaccountname and mail
- It improves sending parameters to the method VerifyWithOtherAuthenticationSource()
- The permits can not be removed for the role processmaker_admin.
- We add a generic list of permissions for the role processmaker_admin located in class.rbac.php.
- Was can remove permissions for the role processmaker_admin but other than those predefined in the list of RBAC.
- The permits can not be removed for the role processmaker_admin.
- We add a generic list of permissions for the role processmaker_admin located in class.rbac.php.
- Was can remove permissions for the role processmaker_admin but other than those predefined in the list of RBAC.
- 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
