====== Notifications - Configure standard notifications ======
This chapter contains a list of important notifications ([[tutorial:adm:notifications_topics|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 [[tutorial:adm:create_provisioning_break|provisioning brake]] is configured and starts braking, IdM will send an email to the configured recipients (usually admins) |
| | acc:provisioningBreakWarning | email | If a [[tutorial:adm:create_provisioning_break|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 [[devel:documentation:bulk_actions|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''. [[tutorial:adm:role_change_notification_configuration|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''. [[tutorial:adm:role_change_notification_configuration|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 [[devel:documentation:password_policies|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 [[devel:documentation:password_policies|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 [[devel:documentation:password_policies|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 ([[https://redmine.czechidm.com/issues/2383|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 [[devel:documentation:modules_vs|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''. [[devel:documentation:roles:adm:role_assignment#notification|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''. [[devel:documentation:roles:adm:role_assignment#notification|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 **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** .