ResourceAttributeDefinitionType (Complex Type)

Items

• ref

  Flags: RAM,runtime

  Multiplicity: [1,1]

• displayName

  Flags: RAM,runtime

  Multiplicity: [0,1]

• description

  Flags: RAM,runtime

  Multiplicity: [0,1]

• displayOrder

  Flags: RAM,runtime

  Multiplicity: [0,1]

• limitations

  Flags: RAM,runtime

  Multiplicity: [0,-1]

• matchingRule

  Flags: RAM,runtime

  Multiplicity: [0,1]

• valueEnumerationRef

  Flags: RAM

  Multiplicity: [0,1]

  Reference to an object that directly or indirectly represents possible values for this item. We do not define here what exactly the object has to be. It can be a lookup table, script that dynamically produces the values or anything similar. The object must produce the values of the correct type for this item otherwise an error occurs.

• tolerant

  Flags: RAM,runtime

  Multiplicity: [0,1]

• tolerantValuePattern

  Flags: RAM,runtime

  Multiplicity: [0,-1]

• intolerantValuePattern

  Flags: RAM,runtime

  Multiplicity: [0,-1]

• emphasized

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Set true for definitions that are more important than others and that should be emphasized during presentation. E.g. the emphasized definitions will always be displayed in the user interfaces (even if they are empty), they will always be included in the dumps, etc.

• deprecated

  Flags: RAM,runtime

  Multiplicity: [0,1]

  This setting can be used to control the value of "deprecated" flag determined from the schema. I.e. it can be used to override the value taken from the schema. E.g. it can be used to "unmark" a deprecated item, so it will behave as normal, non-deprecated item. This may be used as a temporary measure during the period of migrating the configuration to non-deprecated setting.

• experimental

  Flags: RAM,runtime

  Multiplicity: [0,1]

  This setting can be used to control the value of "experimental" flag determined from the schema. I.e. it can be used to override the value taken from the schema. E.g. it can be used to "unmark" an experimental item, so it will behave as normal, non-experimental item. USE WITH CARE. Experimental items are marked as experimental for a reason. When those items are "unmarked", they will not get any less experimental.

• exclusiveStrong

  Flags: RAM,runtime

  Multiplicity: [0,1]

• modificationPriority

  Flags: RAM,runtime

  Multiplicity: [0,1]

• readReplaceMode

  Flags: RAM,runtime

  Multiplicity: [0,1]

• secondaryIdentifier

  Flags: RAM,runtime

  Multiplicity: [0,1]

• volatilityTrigger

  Flags: RAM,runtime

  Multiplicity: [0,1]

  If set to true it indicates that change of this attribute may cause changes in other attributes. In that case midPoint re-reads the object after the change of this attributes.

• displayNameAttribute

  Flags: RAM,runtime

  Multiplicity: [0,1]

• fetchStrategy

  Flags: RAM,runtime,AVals:3

  Multiplicity: [0,1]

• outbound

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Defines how the attribute value is constructed in case of information flow from IDM to the resource, e.g. in case of provisioning. In case an expression is used, the expression variables should be as follows: $user - the user to whom the account belongs $account - the account to be changed Motivation: This is "value construction" type, it is using similar format that is used elsewhere in the system (e.g. in roles) and therefore a common expression processor can be used to process all of that. E.g. a single processor may take into a consideration both schema handling and dynamic attributes set by roles.

• inbound

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Defines how the attribute values are used (assigned) in case of information flow from resource to IDM, e.g. in case of synchronization, reconciliation or discovery. In case a source expression is used, the expression variables should be as follows: $user - the user to whom the account belongs $account - the account that has been changed (after the change) Explanation: This is not a "value construction" as it is not constructing a new attribute value. It is rather using attribute value that was set be someone else. A simpler way how to express the assignment is needed here, especially a simple way how to express assignment target. Some rules may use that information and we definitely need that to generate correct relative change descriptions.