# PrimaryChangeProcessorConfigurationType (Complex Type)

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

Supertype: WfChangeProcessorConfigurationType
Configuration for PrimaryChangeProcessor.

Item Summary
Name | Type | Multiplicity | Description
--- | --- | --- | ---
enabled | property boolean | [0,1] |
order | property int | [0,1] | Order in which the change processor should be invoked.
policyRuleBasedAspect | container PcpAspectConfigurationType | [0,1] | Configuration for a primary change processor aspect.
addAssociationAspect | container PcpAspectConfigurationType | [0,1] | Configuration for a primary change processor aspect.

- ### Items

  - #### enabled

    Flags: RAM,runtime

    Multiplicity: [0,1]

    Display order: 100

  - #### order

    Flags: RAM,runtime

    Multiplicity: [0,1]

    Display order:

    Order in which the change processor should be invoked. (Unspecified means "at the end".) NOT IMPLEMENTED YET.

  - #### policyRuleBasedAspect

    Flags: RAM,runtime

    Multiplicity: [0,1]

    Display order: 200

    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.

  - #### addAssociationAspect

    Flags: RAM,runtime

    Multiplicity: [0,1]

    Display order: 210

    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.