...
| Attribute name | Description |
|---|---|
| deprovisioning | Marker on group/folder |
| deprovisioningAffiliation | Affiliation configured in the grouper.properties |
| deprovisioningDeprovision | true|false, true to deprovision, false to not deprovision (default to true). Note, if this is set on a daemon job, then it will not deprovision any group in the loader job (they will be marked as such) |
| deprovisioningStemScope | one|sub, if in folder only or in folder and all subfolders (default to sub) |
| deprovisioningSendEmail | true|false, default to false. Set this to true for objects where the system of record is outside of grouper or where manual removal is preferred |
| deprovisioningEmailSubject | custom subject for emails, if blank use the default configured subject. Note there are template variables $$name$$ $$netId$$ $$userSubjectId$$ $$userEmailAddress$$ $$userDescription$$ |
| deprovisioningEmailBody | custom email body for emails, if blank use the default configured body. Note there are template variables $$name$$ $$netId$$ $$userSubjectId$$ $$userEmailAddress$$ $$userDescription$$ |
deprovisioningAllowAddsWhileDeprovisioned | If allows adds to group of people who are deprovisioned can be: blank, true, or false. If blank, then will not allow adds unless auto change loader is false |
deprovisioningAutoChangeLoader | If this is a loader job, if being in a deprovisioned group means the user should not be in the loaded group. can be: blank (true), or false (false) |
deprovisioningAutoselectForRemoval | If the deprovisioning screen should autoselect this object as an object to deprovision can be: blank, true, or false. If blank, then will autoselect unless deprovisioningAutoChangeLoader is false |
deprovisioningDirectAssignment | If deprovisioning configuration is directly assigned to the group or folder or inherited from parent |
deprovisioningEmailAddresses | Email addresses to send deprovisioning messages. If blank, then send to group managers, or comma separated email addresses (mutually exclusive with deprovisioningMailToGroup) |
deprovisioningMailToGroup | Group ID which holds people to email members of that group to send deprovisioning messages (mutually exclusive with deprovisioningEmailAddresses) |
deprovisioningSendEmail | If this is true, then send an email about the deprovisioning event. If the assignments were removed, then give a description of the action. If assignments were not removed, then remind the managers to unassign. Can be <blank>, true, or false. Defaults to false unless the assignments were not removed. |
deprovisioningShowForRemoval | If the deprovisioning screen should show this object if the user as an assignment. can be: blank, true, or false. If blank, will default to true unless auto change loader is false. |
| deprovisioningInheritedFromFolderId | Stem ID of the folder where the configuration is inherited from. This is blank if this is a direct assignment and not inherited |
TO DO
- DONE (Chris) Assignment of configuration screen
- DONE API to propagate configuration down to objects
- (Chris) Add in a last reviewed date similar to attestation. Only send emails if the date the user was added to the deprovisioned group is after the last reviewed date
- If user leaves "employee", someone deprovisions a user. Select most checkboxes. Member of deprovision_employees. Email is sent to 3rd party system. Email is just like an attestation. Batched. Link to "review deprovioned users" screen. Screen will show users deprovisioned after the last reviewed date. Check checkboxes (optionally), revmoe users, click button this group has been reviewed.
- If they didnt go to the screen, or not remove users, or not click as reviewed, they would get an email every day for 2 weeks about those deprovisioned users.
- Reviewed sets a date in the attribute for that group
- (Vivek) Daemon to send emails out
- Loop through all affiliations for deprovisioning, loop through all users in those deprovisioned groups, see what memberships/privileges they have, and on those objects see which ones need emails
- If the users deprovisioned membership date is after the last reviewed date for the object where they have a membership or a privilege, and that group/folder/attribute is set to send emails, then an email needs to be sent
- (Vivek) Also send emails out at the time someone is deprovisioned
- API method to send emails at the time someone is deprovisioned
- (Vivek) Email to be sent out
- If the user still has a membership or privilege in the object, include a link to the "remove access and mark as reviewed" screen
- If the user was already removed, but an email should notify, the email should just say the user removed (the daemon emails would never send this)
- Email can be sent to:
- "ADMIN" or "UPDATE/READ" for a group/attributeDef, (or "ADMIN" for a folder since there is not READ/UPDATE) (like attestation)
- comma separated list (like attestation)
- members of a group (different from attestation)
- (Chris) Need a UI screen for group/folder/attribute to show deprovisioned users with memberships/privileges on that group/folder/attribute
- Checkboxes to easily unassign
- Button that allows "mark as reviewed"
- Loader needs to decide if user should be added to loader
- API method to decide this
- Loader integration to use this
- if the attribute: deprovisioningAutoChangeLoader is false, then do not remove from loader job
- (Vivek) API method all groups/folders/attributeDefs of access (move from UI code, add attributes)
- On the UI if someone adds a member, or assigns a privilege, check to see if that user shouldnt be allowed, and prompt the UI person if they are sure
- Should cache members of affiliation deprovisioned groups
- On WS, throw an error if a deprovisioned user is added to a group which shouldnt have it based on configuration
- addMember
- assignPrivilege
- Option to deny deprovisioned adds in grouper-ws.properties, default to on, allow users to disable this
- Should cache members of affiliation deprovisioned groups
- If there is a param in the WS call "overrideDeprovisionedUser" = "true" then allow the assignment
- (LATER) If removed from a role, make sure individual permissions to that user are unassigned as well
- (LATER) Global screen that shows all immediate configuration assignments (like attestation)
- (LATER) If an application owner, they can go to a folder, pull up a user and their access for that folder and easily remove
- Not a global deprovision
- Local to that service
...