An event handler that reacts to the 'Client logged in' event (see Anmeldung (Ereignis) checks in the Validating rule whether the login concerns one of the 'specially privileged roles'.

As can be seen in the screenshot, the relevant Roles can literally be 'handpicked' in a Role rule by multiple selection.

►NOTE◄ The multiple selection label shows the internal role names (roleName) regardless of whether there is a localization or not.

The only Action on passed rule will need to be configured as a Show alert (Popup) event action:

• 'Warning' is selected as the Type so that the notification appears as a 'Warning' (with the default white/orange color scheme).
  
  

• Therefore, as a Title, the system's default label for a warning should also appear. On the system side, there is a Resource warning in the Bundle common, which is suitably localized by default ('Warning'). The Default value common/warning is only relevant in the special case that the localization entry for the Current locale AND for the default locale (if different) is missing.
  
  

• The localization for the Role of session should be displayed in the Message. Localizations for roles refer to the Bundle rolename, where the internal name of the Roles from its rolename field must be specified as the Resource. The same configuration (Role of session and Object property value resolver for roleName) is also set up for the Default value. This is more important here than for the Title, since there is no localization for roles by default. Without localization and without default value, 'No value' ($null) would then be returned.

►NOTE◄ For the Close after (seconds) parameter, the value 0 is specified here so that the warning message remains displayed 'indefinitely' (or until the user closes it). However, it remains visible even if a Fast switch to another (possibly less privileged) role is executed for which no new warning appears.

The screenshot on the right shows in the Preview for E-mails the Subject that is triggered when deleting a role with the internal ID #3302.

The following components are relevant for a localization in the Subject:

• Event ('Delete', 'Create')

• Entity type ('Role', 'User', 'Company account')

For comparison, the screenshot on the right shows an example of a message that was output without localization.

• Here, the text DELETE is the internal name of the 'Delete' event.

• Instead of the entity type, the string mapping of the class for Roles appears.

For e-mail notifications, event handling is configured as shown on the right:

• The default Create and Delete events from the 'Common' category are selected as Triggering events.

• The Validating rule checks by Check type whether it is one of the entity types classified as 'sensitive'. Additional elements can be added to the OR-series.

• Exactly two Actions on passed rule are required:
  
  

  • A Set value event action assigns the account of the user to be notified to the mailToUser variable. In the example, the same user is always assigned, but instead a case distinction or search could be configured to dynamically regulate the responsibility.

  • All other configurations directly affect the following E-Mail event action.

►NOTE◄ Only the localization for the 'Subject' of the e-mail is detailed below.

The text for the Subject within the E-Mail event action is built up step-by-step here using a Concat strings value resolver:

• The first substring of the concatenation outputs the localized name for the event that triggered the event handling.
  
  

  • Since the 'Create' and 'Delete' events both belong to the 'Common' category, we can define the name for the Bundle statically using the Class value resolver, whose string mapping names the bundle: de.lobster.scm.action.event.CommonActionEvent
    
    

  • The key value is provided by the Triggering event value resolver, whose return value can be used as a string mapping directly for the Resource parameter (values: DELETE, CREATE).

  • The Default value repeats the configuration for the Resource parameter, even though localization for common events should be ensured system-side at least by the default locale (as a fallback).
    
    

  • No values are specified for Parameters.
    
    

  • The Locale is assigned from the 'Locale' (locale) field of the user account specified via the mailToUser variable.
    
    

• The second substring specifies a static text (' / ') as separator.

• The third substring outputs the localized name of the entity type that was created or deleted:
  

  • The entityClass variable, which is automatically filled by the system, commonly refers to the class of the reference object and, in the context of a 'Create' or 'Delete' action, to the type of entity in question.The string mapping of the class can be assigned directly to the Bundle parameter here.
    
    

  • The localized name for an entity type is retrievable by default via the Resource $name.
    
    

  • Even though system localizations should be retrievable at least for the default locale of the entity types relevant in the example, the Default value here is also assigned to the $name string. If necessary, the value of the variable entityClass could be added via Concat strings.
    
    

  • The Locale is read from the account of the contacted user, as described above.
    
    

• The fourth substring defines a static text (' #') for separation and as a prefix for the following ID (id).
  
  

• The fourth substring identifies the reference object for the event , i.e. the entity to be created or deleted, via its field ID (id).
  ►IMPORTANT◄ Since a new entity in the context of the 'Create' event does not yet have an ID, the 'Create mail content on commit' option should be selected for the E-Mail event action, otherwise the ID 0 will be issued.

Instead of the Concat strings value resolver, another instance of the Value from localization value resolver is set up in the configuration shown on the right:

• The outer Value from localization value resolver serves here only as a platform to bring the Default value ({0} / {1} #{2}) into play. The Bundle and Resource parameters remain empty, as we are not actually looking for a localization entry value.
  
  

• The list of Parameters can be 'taken' by copying and pasting the configurations for the corresponding substrings from the subject:
  
  

  • The first Parameter ({0}) provides the localization for the triggering event via a Value from localization value resolver (see above for details).
    
    

  • The second Parameter ({1}) provides the localization for the entity type via a Value from localization value resolver (see above for details).
    
    

  • The third Parameter ({2}) returns the ID (id) of the created or deleted entity (see above), which works without accessing the localization.

Runtime example:

As a screenshot of the e-mail preview proves, this configuration provides the same text for the 'mail body' as the one shown above for the Subject.

The 'concat strings' per Default value is even clearer and more flexible, especially if the order of the placeholders for parameters is changed later or the same parameter is 'quoted' several times.