PrimaryChangeProcessorConfigurationType (Complex Type)

Items

• enabled

  Flags: RAM,runtime

  Multiplicity: [0,1]

• order

  Flags: RAM,runtime

  Multiplicity: [0,1]

• policyRuleBasedAspect

  Flags: RAM,runtime

  Multiplicity: [0,1]

  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.

• addUserAbstractRoleAssignmentAspect

  Flags: RAM,runtime

  Multiplicity: [0,1]

  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.

• modifyUserAbstractRoleAssignmentAspect

  Flags: RAM,runtime

  Multiplicity: [0,1]

  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.

• addUserResourceAssignmentAspect

  Flags: RAM,runtime

  Multiplicity: [0,1]

  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.

• modifyUserResourceAssignmentAspect

  Flags: RAM,runtime

  Multiplicity: [0,1]

  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.

• addAbstractRoleAbstractRoleAssignmentAspect

  Flags: RAM,runtime

  Multiplicity: [0,1]

  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.

• modifyAbstractRoleAbstractRoleAssignmentAspect

  Flags: RAM,runtime

  Multiplicity: [0,1]

  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.

• addAbstractRoleResourceAssignmentAspect

  Flags: RAM,runtime

  Multiplicity: [0,1]

  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.

• modifyAbstractRoleResourceAssignmentAspect

  Flags: RAM,runtime

  Multiplicity: [0,1]

  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.

• addAbstractRoleAspect

  Flags: RAM,runtime

  Multiplicity: [0,1]

  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.

• modifyAbstractRoleAspect

  Flags: RAM,runtime

  Multiplicity: [0,1]

  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.

• addUserAspect

  Flags: RAM,runtime

  Multiplicity: [0,1]

  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.

• modifyUserAspect

  Flags: RAM,runtime

  Multiplicity: [0,1]

  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.

• addResourceAspect

  Flags: RAM,runtime

  Multiplicity: [0,1]

  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.

• modifyResourceAspect

  Flags: RAM,runtime

  Multiplicity: [0,1]

  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]

  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.

• otherAspect

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  A generic configuration for a wf aspect. It is meant for non-standard aspects. (Standard aspects use named properties in PrimaryChangeProcessorConfigurationType container.)