Expression Profiles Coverage

Last modified 29 Aug 2024 14:32 +02:00

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

Actions

Explicitly supported profiles are the following ones:

  1. Profiles for actions in task templates.

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

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

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

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

Actions provided via GUI or REST

N/A

TestExpressionProfiles.test310UntrustedBulkExecutingScriptDirectly and following tests

Actions in an iterative scripting task

activity/work/iterativeScripting/scriptExecutionRequest

TestTrustedBulkActions.test100TemplateWithoutProfile

Actions in an non-iterative scripting task

activity/work/nonIterativeScripting/scriptExecutionRequest

TestTrustedBulkActions.test105TemplateWithoutProfileNonIterative

Actions in policy constraint

assignment/policyRule/policyConstraints/objectState/executeScript

TestTrustedBulkActions.test200PolicyRule

Actions in policy action

assignment/policyRule/policyActions/scriptExecution/executeScript

TestTrustedBulkActions.test200PolicyRule
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:

TODO

Mappings

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

[EP:M:IM]

inbound mappings

Inbound mappings come from the particular resource.

OK (Except for resource inheritance.)

attribute, association, and auxiliary object class definitions

[EP:M:OM]

outbound mappings

OK (Except for resource inheritance.)

[EP:M:AFM]

assigned focus mappings

OK

[EP:M:AAFM]

auto-assignment focus mappings

OK

[EP:M:TFM]

template focus mappings

OK

[EP:M:ARC]

assignment or role condition

The assignment and role conditions are evaluated as mappings.

OK

assignment condition

role condition

[EP:M:PRC]

policy rule condition

The policy rule conditions are evaluated as mappings.

OK

systemConfiguration:globalPolicyRule/condition

not needed

mark:policyRule/condition

TODO

[EP:M:MM]

metadata mapping

This is experimental functionality, anyway.

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

[EP:M:Tag]

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.

Limitations

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?
YES NO
Thanks for your feedback