We had a similar question (and found the same answer)...but we also found some additional requirements around security group provisioning...because Maximo "access" is actually scattered across a lot of different objects (security group membership, person group membership, default queries, and default insert site), it can be very difficult to EASILY answer the question "if a person fills a particular role, what should their Maximo configuration look like?"...
To this end, we have configured our Security Group application to include the configuration of "roles". This is accomplished using the following components (we often add the suffix _GRE to field names to ensure uniqueness):
- Added a checkbox ISROLE_GRE to the MAXGROUP object to designate which security groups are configured with "role-type" information
- Added a required field PROCESS_AREA to the MAXGROUP object attached to a domain...this allows a role security group to be designated as part of a particular enterprise process area
- Added a required field ROLE_GRE to the MAXGROUP object that serves as a unique identifier for the "name of the role" inside the process area
- Added an object DFLT_ROLES_GRE that ties to the MAXGROUP object 1:M--each row includes checkboxes for "Provision" and "Deprovision"..."provision" means that the value specified in the row should be ADDED for the designated user when the user is added to this role security group, and "deprovision" means that if the user is REMOVED from the role group, they should also have the designated access for that row removed. Each row can have exactly one type:
- Security Group (user should be added or removed from this group)
- Person Group (user's person record should be added or removed from this group)
- Default query / application
- Default insert site
- "Include"--allows for one role group to be leveraged in other role groups
- Added nonpersistent fields PROCESS_AREA and DFLT_USER_ROLE_GRE to the MAXUSER object to make provisioning easier
- Added action and associated script to User application for "provisioning"...just makes things a bit smoother and allows for the use of nonpersistent fields
- Added a script GROUPUSER.INSERT that uses any role-based information and adds & configures users as defined
- Added a script GROUPUSER.DELETE that uses any role-based information and removes & configures users as defined
- (Additionally, we have added a field CONDITIONNUM to the MAXGROUP object and have augmented the CONDITION object with ties to MAXMESSAGES...this allows authorized users to specify a condition that must evaluate to TRUE before a user can be added to a particular security group, AND it allows the condition to have a configured message that should be displayed if the condition is not met...this is supported by a script that fires on GROUPUSER.USER to evaluate any present condition and throw an error if not met)
Screenshots and scripts attached...obviously there are other little pieces here and there that help support this, but this is the bulk of it.