Notifications - Configure standard notifications
This chapter contains a list of important notifications (topics) available in CzechIdM, especially those sent by email.
The column "Check" marks the notifications, which we recommend to check during the installation of CzechIdM. These notifications can be sent to common users by some action of the administrator in IdM and they are enabled by default.
The notification about creating a new approval task is not sent by default. You must enable it - see core:wfTaskCreated below.
| Check | Topic | Channel | Note / usage |
|---|---|---|---|
| CHECK | acc:newPassword | After creating a new system account, IdM will send the generated password to the user, who is the owner of the account. This can be turned off by deactivating the provisioning-send-notification-processor processor |
|
| acc:provisioning | websocket | IdM displays information about the result of provisioning to a system (can be visible also after approving a role request) | |
| acc:provisioningBreakDisable | If a provisioning brake is configured and starts braking, IdM will send an email to the configured recipients (usually admins) | ||
| acc:provisioningBreakWarning | If a provisioning brake is configured and the warning limit is reached, IdM will send an email to the configured recipients (usually admins) | ||
| core:bulkActionEnd | IdM will notify the user, who started some bulk action, about the result of the action | ||
| CHECK | core:changeIdentityRole | After changing assigned roles of the user manually (after the role request is finished - by default without approving), IdM will send the information to the user, whose roles were changed. This can be turned off by the configuration property idm.sec.core.wf.notification.applicant.enabled=false. Read more |
|
| CHECK | core:changeIdentityRoleImplementer | After changing assigned roles of the user manually (after the request is finished), IdM will send the information to the user, who requested the change. This can be turned off by the configuration property idm.sec.core.wf.notification.implementer.enabled=false. Read more |
|
| CHECK | core:disapproveIdentityRole | Same as core:changeIdentityRole, only for disapproved requests | |
| CHECK | core:disapproveIdentityRoleImplementer | Same as core:changeIdentityRoleImplementer, only for disapproved requests | |
| core:loginBlocked | If maximum login attempts is specified in the password policy and a user exceeds this limit, this notification is sent to the user. | ||
| CHECK | core:passwordChanged | Users are notified about every change of their passwords. This can be turned off by deactivating the identity-password-change-notification processor |
|
| CHECK | core:passwordSet | The standard HR process (the scheduled task HrEnableContractProcess) resets the password and sends it to the user, when the user is activated for the first time (his first contract starts). This can be turned off by deactivating the identity-set-password-processor processor |
|
| core:passwordExpirationWarning | If the maximum password age is configured in the password policy and the task PasswordExpirationWarningTaskExecutor is scheduled, IdM will send this notification to the users about near password expiration | ||
| core:passwordExpired | If the maximum password age is configured in the password policy and the task PasswordExpiredTaskExecutor is scheduled, IdM will send this notification to the users about their expired password | ||
| CHECK | core:returnRequestIdentityRole | Same as core:changeIdentityRole, only for returned requests | |
| CHECK | core:returnRequestIdentityRoleImplementer | Same as core:changeIdentityRoleImplementer, only for returned requests | |
| CHECK | core:wfTaskAssigned | Disable this topic, if you use version 10.4 or newer, because it causes duplicate notifications on this version (see more). For older versions, it's recommended to disable it as well. For 10.5+, this topic will be probably deprecated/removed. | |
| CHECK | core:wfTaskCreated | If an approval task is created for the user, the user will be notified about the task. This is must be enabled by configuration property idm.sec.core.wf.notification.send=true. The notification contains URL to the task, so URL of the server (e.g. https://idm.domain.tld) must be set as first value in the configuration property idm.pub.security.allowed-origins. |
|
| vs:vsRequestCreated | If a new request on a virtual system is created, the implementer of the virtual system will be notified about the request | ||
| core:changeIdentityRole (topic: core:roleRequestRealizedApplicant) | After changing assigned roles of the user manually (after the role request is finished on all systems - by default without approving), IdM will send the information to the user, whose roles were changed. This can be turned off by the configuration property idm.sec.core.wf.notification.applicant.enabled=false. Read more. It can be turned on by activating the topic. |
||
| core:changeIdentityRoleImplementer (topic: core:roleRequestRealizedImplementer) | After changing assigned roles of the user manually (after the request is finished on all systems), IdM will send the information to the user, who requested the change. This can be turned off by the configuration property idm.sec.core.wf.notification.implementer.enabled=false. Read more. It can be turned on by activating the topic. |
||
| core:uniformPasswordSet | Is send after contract sync end. For identities where some account was created (contains uniform password). |
A processor can be deactivated in Settings → Modules → Processors by clicking on the button Deactivate.
A configuration property can be set in Settings → Configuration.
A topic can be (de)activated in Notifications → Configuration → magnifying glass → Inactive .