Configuration for a primary change processor aspect. Some aspects do not require any configuration - for example, role and resource assignment ones. They take all the approver information directly from the object (role or resource) being assigned. However, there are some others (namely, role/resource/user/whatever add/modify aspects) that need the explicit information about approver(s) in order to know where to route the request. For the former aspects, the approver information specified here takes precedence over approver information derived from the objects being used (e.g. role or resource). More specifically, if any approver information is here, no approver information is taken from the objects. This could be changed (e.g. by allowing to tune this behavior) in the future.

Item Summary
Name	Type	Multiplicity	Description
$itemDefinition.Name.LocalPart	property boolean	[0,1]	Whether the aspect is enabled or not.
$itemDefinition.Name.LocalPart	reference ObjectReferenceType	[0,-1]	Approvers for this aspect.
$itemDefinition.Name.LocalPart	property ExpressionType	[0,-1]	Approvers for this aspect.
$itemDefinition.Name.LocalPart	container ApprovalSchemaType	[0,1]	More complex (multi-stage) approval schema.
$itemDefinition.Name.LocalPart	property string	[0,1]
$itemDefinition.Name.LocalPart	property ExpressionType	[0,1]	Condition specifying when the item is automatically approved (e.
$itemDefinition.Name.LocalPart	property ExpressionType	[0,1]	Condition specifying if the workflow should be started in the first place.

Items
- $itemDefinition.Name.LocalPart
  
  Flags: RAM,runtime
  
  Multiplicity: [0,1]
  
  Whether the aspect is enabled or not. If not specified (but if aspect configuration is present), it is assumed to be true. However, if the whole aspect configuration is absent, only aspects marked as "enabled-by-default" are enabled.
- $itemDefinition.Name.LocalPart
  
  Flags: RAM
  
  Multiplicity: [0,-1]
  
  Approvers for this aspect. The approver is a person (or group) that approves carrying out action(s) relevant to this aspect. This reference may point to object of type UserType of OrgType.
- $itemDefinition.Name.LocalPart
  
  Flags: RAM,runtime
  
  Multiplicity: [0,-1]
  
  Approvers for this aspect. If specified, the expression(s) are evaluated and the result is used as a set of approvers (UserType, OrgType, or any combination of them). May be used with approverRef element(s).
- $itemDefinition.Name.LocalPart
  
  Flags: RAM,runtime
  
  Multiplicity: [0,1]
  
  More complex (multi-stage) approval schema. If used, it overrides both approverRef and approverExpression elements.
- $itemDefinition.Name.LocalPart
  
  Flags: RAM,runtime
  
  Multiplicity: [0,1]
- $itemDefinition.Name.LocalPart
  
  Flags: RAM,runtime
  
  Multiplicity: [0,1]
  
  Condition specifying when the item is automatically approved (e.g. "user is from Board of Directors"). This is an expression that should yield a boolean value.
- $itemDefinition.Name.LocalPart
  
  Flags: RAM,runtime
  
  Multiplicity: [0,1]
  
  Condition specifying if the workflow should be started in the first place. This is an expression that should yield a boolean value. It gets 'itemToApprove' parameter that contains item to be approved - it is aspect-specific: might be e.g. an assignment, an association + resource shadow discriminator, etc. The difference between applicabilityCondition and automaticallyApproved is that if the former yields false, workflow is not even started. If it yields true, workflow is started, and then 'automaticallyApproved' is evaluated. If it yields false, manual approval is required. If true, item is automatically approved. CURRENTLY IMPLEMENTED ONLY IN AddAssociationAspect.

PcpAspectConfigurationType (Complex Type)

Namespace: http://midpoint.evolveum.com/xml/ns/public/common/common-3

Items

$itemDefinition.Name.LocalPart

$itemDefinition.Name.LocalPart

$itemDefinition.Name.LocalPart

$itemDefinition.Name.LocalPart

$itemDefinition.Name.LocalPart

$itemDefinition.Name.LocalPart

$itemDefinition.Name.LocalPart