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 email 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 email If a provisioning brake is configured and starts braking, IdM will send an email to the configured recipients (usually admins)
acc:provisioningBreakWarning email 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 email IdM will notify the user, who started some bulk action, about the result of the action
CHECK core:changeIdentityRole email 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 email 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 email Same as core:changeIdentityRole, only for disapproved requests
CHECK core:disapproveIdentityRoleImplementer email Same as core:changeIdentityRoleImplementer, only for disapproved requests
core:loginBlocked email 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 email 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 email 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 email 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 email 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 email Same as core:changeIdentityRole, only for returned requests
CHECK core:returnRequestIdentityRoleImplementer email Same as core:changeIdentityRoleImplementer, only for returned requests
CHECK core:wfTaskAssigned email 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 email 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 email 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) email 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) email 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 email Is send after contract sync end. For identities where some account was created (contains uniform password).
A processor can be deactivated in SettingsModulesProcessors by clicking on the button Deactivate.

A configuration property can be set in SettingsConfiguration.

A topic can be (de)activated in NotificationsConfiguration → magnifying glass → Inactive .

  • by svandav