...
- 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
- Done (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
- Done (Vivek) Also send emails out at the time someone is deprovisioned
- API method to send emails at the time someone is deprovisioned
- Done (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"
- Done (Vivek) 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) Dont deprovision the deprovision group itself... startup? add settings?
- Done (Vivek) API method all groups/folders/attributeDefs of access (move from UI code, add attributes)
- (LATER) 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
- (LATER) 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
- (LATER) add notes and keep track of what was deprovisioned
- (LATER) put message on group membership screen if there are (cached) entries in deprovisioning report
- (LATER) use the "in affiliation" group on deprovisioning reports. or wider group? active?
...