I think another way to approach that problem is to alter the "Add Role" function so that a User Manager can only add a role that they themselves have. Then User Managers who are not themselves Admins can't escalate their own privileges, nor de-escalate other Admins.

That necessitates your User Manager having all the roles you might want that person to administer. I don't think that would often be a big problem, though. In fact, it would allow you to make an 'Acquisitions focused' User Manager and a 'Fulfillment focused' User Manager, etc., if you so desired.

> Is there a date when this is planned?

June 2020
https://knowledge.exlibrisgroup.com/Alma/Release_Notes/2020/Alma_2020_Release_Notes?mon=202006BASE#Limit_User_Manager_Role_by_Account_Type-80104

This is exactly what I am looking for! We want the ability to toggle old external student accounts to internal Community Borrower accounts at the Service Desk. Old students can be from Cont Ed or the Conservatory so this is an issue for us. At this time, only User Manager and User Administrator have the Toggle Account Type privilege. I do not want all the other privileges though, especially managing roles, to be given to Service Desk staff.

Is there a date when this is planned? I cannot find it on the Alma Roadmap.

The Planned solution is a step in the right direction, but we should go further. Per the principles of segmentation of responsibility and user empowerment, role provisioning within the product should allow for managers within a functional area (role area) and/or organizational unit (scope) to manage the associated privileges, and only the associated privileges, of that functional area and/or organizational unit.

For example, a Role of User Manager could be assigned within the Role Area of "Fulfillment" and a Scope of "Main Library". As such, a Circulation Manager in the Main Library with that role assignment could assign (and unassign) roles within that Role Area and Scope, but only within that Role Area and Scope.

Moshe thanks for following up with me. You are correct regarding the circulation desk operator not requiring User Manager. We were in the throes of implementing Alma and did not accurately understand which roles were required in order to register a new patron.

Mark

A circulation desk operator should not require the User Manager role for registering a new patron. That is possible with the circulation desk operator role.

Hello,

In our library, the staff who work at the main circulation desk, need to be able to create new Alma users for new patrons who walk in. My understanding is that this requires them to have the User Manager role which also enables them to modify roles/privileges.

Mark

Hi,

Circulation desk operators can add and edit phones/emails, but cannot add/remove roles from users. Is that not your experience ?

Moshe

Moshe I am glad that addressing this issue is a planned enhancement. Staff who can add patrons and update phone numbers should not be able to give themselves admin privileges or modify privileges of other staff or patrons. It seems like either a new role could be added which permits adding and updating all except User Roles (the security/permission system of Alma), or these abilities could be revoked from User Manager.

Regarding your description of what is planned, I don't fully understand what is being proposed, but I do have a couple of questions/comments on what is described.

- You describe, "allowing to limit the role to specific account types – staff/public." We are in the process of Alma migration and have been instructed that all Alma users will be the public staff type, our library staff and library patrons. Only Ex Libris generated accounts are to have the staff account type. So this limit seems good but will not prevent editing of library staff permissions.

- You describe, "A user with manger/administrator role will have edit/delete access only to records of users that don’t have any of the roles in the ‘Limited access user roles’ table and their user group is not in the ‘Limited access user groups’ list , unless his role has the ‘allowed access to all users’ attribute on. The user will still be able to view the limited access user records." If I am understanding this correctly it means that most staff with User Manager role would not be able to modify the roles/permissions or other fields of library staff (assuming the OTB settings you describe). Only staff who have the responsibility of managing Alma privileges(roles) would be enabled to modify these Alma users at all. Would this also prevent a Circ Operator from being able to add Administrator roles to an Alma User who currently only has the Patron role (a user they are able to edit)?

Thanks for working on this,
Mark

6348 made it to round two in the NERS voting -> June 2019.

I agree, it should be anb out of the box solution.

Ennio

Ohh... my god! Thanks Paolo

Thank you all for your feedback! In my opinion this should be an out of the box solution, not a customization done upon request.
Let me add that this idea is currently also one of the 19 that are currently on the second NERS ballott.
Best
Paolo

As followup, pending any future enhancement, this change may be made on request for your Alma instance by submitting a Salesforce case to remove the following privileges from User Manager role: USER_MANAGER_ADD_ROLE, USER_MANAGER_UPDATE_ROLE, USER_MANAGER_DELETE_ROLE. QUT case #00559228 refers.

Agree there needs to be more granular control here over role assignment privileges (particularly to restrict the ability of User Manager to upgrade user records with General System Administrator role or other *Administrator roles). It seems that Adelaide, based on Chris Sloan's previous comment, had a custom configuration change made to resolve the issue for their site and I'll be investigating that as an interim measure here at QUT. Based on privileges report there may be a number of different values involved apart from USER_MANAGER_ADD_ROLE.

I agree with Michael Voss. It would be great to have more control over privileges in general. That would be a solution to this request.

Yes, please!

I like this a lot! They could also be called User Manager and Roles Administrator.

I think - the easiest way to solve such thinks is, to give us the possibility to create our own roles based on the given privileges.

We have this enabled in our instance at Adelaide. Only User Administrator role has the ADD_ROLE privilege, User Manager role does not (case #00151491, unpublished)