Created a New Role to add/remove group members, assign another manager, set parent/type/group email

[rishabh31]

Dear Team,

I am a bit new to creating such a role.

As an admin user, I want the ability to assign another ITIL user an "assignment group manager" role that allows the ITIL user the ability to add/remove group members, assign another manager, set the type, edit description, set group email and set parent group when they are assigned to the manager field in the assignment group so that an admin role does not need to do this on every assignment group. (below screenshot with highlighted fields/related list that needs to be editable through this new role)

For this, I have created a new role and assigned a module (see the below screenshot)

Then I assigned this newly created role to an itil user and impersonated him to check, and found they are not even able to see Group so ability to add/remove group members, assign another manager, set the type, edit description, set group email and set parent group is also not acheived.

Please help to get this fulfilled as I am confused here

Thank You

[Claude DAmico]

Not being able to see Group is probably because of the access to the User Administration and Group modules which is usually reserved for users with user_admin, admin, or role-delegator roles. Group in particular, in my PDI, shows requires user_admin role. You could update the application and module navigation items to include the new role so they are visible.

For the access to read/write on the Group records, check the ACLs that grant those rights. You might be able to just add the new role to those ACLs. That would grant access on records without being the Manager though so your use case might require a new ACL for read and write to account for the user having the correct role and the user being in the Manager field.

[-O-]

Existing O(ut) o(f the) B(ox) role user_admin pretty much does what you have described.

Why do you want to duplicate existing OOB functionality?

[rishabh31]

@-O- Sir, because user_admin role allows access to all different tables as well and I want only aforesaid functionality so that is why created this new role

I am nearby to get this achieve, now I can access the Group Module/sys_user_group table through the assignment of this newly created role (Pls see the below screenshot) also able to access/modify each field of any Group record only if Manager is dynamic(me)-

But I want to make only 'read' access to 'Name' (currently 'Name' has 'write' access) if the user contains this new role, I tried to modify the below OOB ACL for 'Name' by adding this newly created role and modify the condition to Manager is Dynamic(me) and even created a new ACL with same configs but still won't work, please advise how to make only 'Name' field as Read. 

Thank You

[-O-]

You need to create several ACLs, not just one, and you should avoid configuring one role as including another from two different security "areas".

I mean it would be OK to make an "incident_admin" role to include "incident_create", "incident_write" and "incident_read", but it would NOT be OK to make "incident_admin" include "change_admin".

One will have just killed any possibility of segregating access - the very reason why security area roles have been created.

Back to your specific requirements, you should NOT make itil include your new user role, but you should create a group, grant the role to that group and add the relevant users to that group. Or in case there already is a group that contains exactly the users who should have your new role, you should grant your new role to that group.

To grant access to the enumerated fields of group, you need to create many more than one or a couple of ACLs.

You will need to create a record-write ACL, but also field-write ACLs.

You will need to create the record-write ACL that has Name=sys_user_group and than one for each field, ACLs where Name=sys_user_group.name, Name=sys_user_group.manager, a.s.o.

You will need to create record-create, record-read, record-write and record-delete ACLs for the group membership records too, making sure to not grant create that would allow a user having your new role to create records that could lead to elevation; e.g. make themselves members of groups that have admin role granted.

However there is a security hole in your requirement: if a user can set group management at will, the restriction to only allow some updates if the current user is the manager of a group is pointless: any user can just temporarily make himself the manger of the group, do the required (theoretically unauthorized) changes, than reset the manager to the original one.