Expression Profiles Coverage

Last modified 04 Sep 2023 21:23 +02:00
Since 4.8
This functionality is available since version 4.8.

The coverage by expression profiles is NOT COMPLETE.

This means that even if an object has attached an expression profile through its archetype, the profile may not be consistently applied to all expressions present in that object.

Supported Profiles

Bulk Actions

Explicitly supported profiles are the following ones:

  1. Profiles for bulk actions in task templates.

  2. Profiles for bulk actions in policy rules in objects: both in conditions and actions of these rules.

  3. Profiles for bulk actions entered via GUI ("Bulk actions" page) and via REST ("/rpc/executeScript").

This means that the specified profiles are applied to bulk actions and any expressions contained in them for these cases.

Table 1. Support for expression profiles for bulk actions
Description Covered path Reference

Bulk actions provided via GUI or REST


TestExpressionProfiles.test310UntrustedBulkExecutingScriptDirectly and following tests

Bulk actions in an iterative scripting task



Bulk actions in an non-iterative scripting task



Bulk actions in policy constraint



Bulk actions in policy action



The reference above means the test method(s) that check that the profiles are really applied. It is obviously not a proof of correctness and/or completeness of the implementation, just a reminder that it was tested to some degree.

Profiles Supported Experimentally

As an experimental feature, expressions profiles (EPs for short) are supported also at the following places:



The whole mapping evaluation (including the "main" expression, condition, value set expressions, and so on) is driven by expressionProfile in AbstractMappingImpl class. (The fact that really all the expressions are supported is a question of thorough testing and/or code analysis.)

This field is set when the class is instantiated, and is determined from the mapping origin, using ExpressionProfileManager.determineExpressionProfileStrict method that does not accept unknown or external origins.

So, the crucial thing is to identify the origin of a mapping correctly.

Currently, the mappings can be used in the following places TODO fill the table:

Ident Place Description Status Path Reference


inbound mappings

Inbound mappings come from the particular resource.

OK (Except for resource inheritance.)

attribute, association, and auxiliary object class definitions


outbound mappings

OK (Except for resource inheritance.)


assigned focus mappings



auto-assignment focus mappings



template focus mappings



assignment or role condition

The assignment and role conditions are evaluated as mappings.


assignment condition

role condition


policy rule condition

The policy rule conditions are evaluated as mappings.



not needed




metadata mapping

This is experimental functionality, anyway.

OK (Not sure about object template inclusion, though.)


shadow tags

(Outbound) shadow tags are computed as mappings.

OK (Except for resource inheritance.)

The status of OK means that the code was checked for compliance. However, no guarantees can be provided at this time.


Configuration items in resources are currently determined without taking resource inheritance into account. See also MID-9018.

The effects of object template inclusion are unclear. See e.g. [EP:M:MM].

Was this page helpful?
Thanks for your feedback