For a admin-level explanation of notifications, click here.
As for the architecture, the (preliminary) structure is the following:
Currently there are three channels through which notifications are sent:
- Resource operation listener. When provisioning module carries out an operation (either successfully or not), it invokes registered operation listeners. One of them is AcccountOperationListener, which
- Model change hook. As model progresses through a change execution, it invokes registered change hooks. One of them is NotificationChangeHook, which acts upon an operation in its FINAL phase. After it detects a situation it is interested in, it creates a notification request and passes it to NotificationManager. (Was implemented, but currently not used.)
- Activiti Java delegate. At specified points in workflow processes there may be needed to send user notifications. Activiti uses a concept of a Java delegate to invoke custom java functionality. NotificationJavaDelegate is such an interface to our notification framework. (It is not implemented yet.)
Note: In the following table, there are the following roles mentioned:
- REQUESTER, i.e. the one who requested an operation. He may be actually the real requester (e.g. user's manager) or the user himself (in such case, REQUESTER = REQUESTEE), or IT administrator using midPoint. This depends on how midPoint is used.
- RESOURCE_ADMIN, i.e. an administrator of a resource; should be defined as Resource attribute.
- IDM_ADMIN should be defined in System Configuration.
- ANY_OTHER should be defined as a constant or an expression somewhere (maybe in workflow configuration or System Configuration?) - an example: security administrator.
MidPoint user creation
REQUESTEE: provide status. If password was generated, provide the password.*
MidPoint user change (attributes, roles, accounts assigned, org units, ...)
REQUESTEE: provide status and information about changes.
Change on resource (add/remove account, add/remove group membership, attribute change, ...)
REQUESTEE: provide status and information about changes, e.g. new/removed privileges, new logins and/or passwords.
MidPoint user deletion.
REQUESTER: provide status.
REQUESTEE or REQUESTER: provide new password (see note * in first row).
Automatic Provisioning and identity lifecycle maintenance (e.g. LiveSync)
IDM_ADMIN: Provide status. If the password was generated, provide password.
Before: Send approval requests to APPROVER.