Skip to end of metadata
Go to start of metadata

Information generated by policy rules are currently used at many places in midPoint:

  1. work item name
  2. work item 'additional information' (shown to approver)
  3. process name
  4. process 'additional information' (shown to approver or any other authorized user)
  1. reason why the given object or assignment modification is being approved - e.g. just because the role assignment needs to be approved, or because of SoD rule, or because some business rule (which one?) is not adhered to and requires manual confirmation
  2. more specific information related to the reason, e.g.
    1. which roles are in SoD conflict with the one that is being assigned
    2. specific values of items that are not correct
  3. any existing approvals/certifications issued so far: either just "who" and "valid to", or the whole record of related actions and their outcome.

E.g. process or work item names could be:

  1. Approve modification of user XYZ (this is the most generic name)
  2. Approve activation of role XYZ (e.g. when lifecycle state is being set from "draft" to "active")
  3. Approve activation of role XYZ violating business rules BR123 and BR456 (e.g. when lifecycle state is being set to "active" but some rules are violated)
  1. GUI that shows the error message for attempted operation
  2. information for any other client (REST, SOAP, bulk action, ...) that requested the attempted operation
The same as above: what went wrong (SoD, business rule, ...) and with what parameters. Maybe also related actions. (If e.g. some grace period expired.)
approvals and enforcement preview
  1. when user clicks on "preview changes" in regular GUI
  2. when user inspects his role shopping cart

The same as above: what went wrong (SoD, business rule, ...) and with what parameters. Maybe also related actions.

For approvals we could want to see preview of the approval process.

  1. certification work item: when reviewer wants to learn why given certification work item was presented to him
  2. certification campaign: when someone wants to see what is being certified in a given campaign (e.g. "this is campaign to certify SoD violation", or "this is campaign to certify violations of BR123 and BR456").
The same as above: what went wrong (SoD, business rule, ...) and with what parameters. Maybe also related actions.
notificationMessage sent to the user (in various formats: mail, SMS, ...)The same as above: what went wrong (SoD, business rule, ...) and with what parameters. Maybe also related actions.
remediationThis is a manual action, probably similar to an approval workflow. Maybe it will be the case management that will be used.The same as above: what went wrong (SoD, business rule, ...) and with what parameters. Maybe also related actions.
ad-hoc certificationAd-hoc certification campaign is started. So we want to learn about the reason either when reviewing a given work item or when we look at the whole campaign.The same as above: what went wrong (SoD, business rule, ...) and with what parameters.
reportingReports on violations of business rules.From simple count and object/assignments lists that violate a specific business rule to detailed information on which business rule is broken and with what parameters.
bulk actionSynchronous or asynchronous execution of a bulk action.The same as above: what went wrong (SoD, business rule, ...) and with what parameters. To be shown e.g. when looking at background task carrying out the bulk action.


  1. All texts (process and work item names, process and work items additional information, enforcement error messages, ...) must be localizable.

How to specify the information to be conveyed to users? From the most specific to most generic ways:

1channel-specific facilitiesusing generic/custom notifiers (defined in system configuration)
2policy action specific configuration

additionalInformation expression in approval stage definition

custom message definition in enforcement action (not yet implemented)

approvalDisplayName in process specification or approval action itself

3generic or specific information added to policy rule and/or individual constraints

constraint or policy rule name/description - like "trying to activate role without an owner"

some "localizable user message" with optional parameters (defined by expressions) to either policy rule or a key constraint (not yet implemented)

4built-in knowledge about constraints

SoD (exclusion) constraints have knowledge of targets that are excluded; so we just want to convey information on these when dealing with exclusion information

min/max assignees constraints again have all the information we need to show

According to the best midPoint traditions we prefer 4 before 3 before 2 before 1.

TODO write detailed information here

Approval display name, i.e. something that is put into work item names, approval process instance names and approval task names, is derived from (first one that exists applies):

  1. policyActions/approval/processSpecification/approvalDisplayName
  2. policyActions/approval/approvalDisplayName (considered in the order of approval actions application, directed by compositionSpecification)
  3. policyConstraints/(constraint)/presentation/shortMessage

If #default# is used as a key name in the message being applied it means that the default message (e.g. Assigning role "A" to user "U", Modifying assignment of org "O" on user "U", etc.)

Some examples


Some ideas

presentation element on policy constraints

messageMessage to be conveyed to the user. It is a LocalizableMessage (or equivalent), having key, parameters, and fallbackMessage.todo
shortMessageVery short message describing the situation. Could be used for e.g. notification messages subject, approval process or work item names. TODO. Again, a LocalizableMessage.todo
longMessage(TODO better name) - long, documentation-like explanation of the rule 
importanceHow important is this particular information. E.g. major, normal, minor, none (or should we use numbers to provide more flexibility?). By default, only the highest-level messages are shown. If requested, user could view also lower-level messages.todo

Alternative 1: Persistence

Triggers and situations take storage place and processing time when maintaining. So they are made configurable with regards to their storage using the following two parameters of policy constraints:

situationPersistenceShould the situation stemming from this constraint be persistently stored?full, none
triggerPersistenceShould the trigger stemming from this constraint be persistently stored?full, user-information, user-information-highest, none

Alternative 2: Expected use

Value of expectedUse propertyMeaning 
certificationSituation and triggers will be stored. 
brief-reportSituation will be stored but no triggers. 
full-reportSituation and triggers will be stored. 

Storage conservation (if triggers are to be stored)

Value of storageCompaction propertyMeaning
fullOnly message and short message will be stored.
normalWhole triggers will be stored. (But only those that are directly marked with expectedUse property.)
noneWhole triggers will be stored, including subtriggers.


An example

Example of user information

Another example - a policy rule attached to roles that could not be assigned to users from cost centers 1900-1999 without special approval:

Role could not be assigned to users from specified cost centers
  • No labels