ResourceAttributeDefinitionType (Complex Type)

Items

• ref

  Flags: RAM,runtime

  Multiplicity: [1,1]

  Path of the item or association that this definition describes. It must point to property or the attribute in the resource schema that belongs to an object class that is being described here.

• displayName

  Flags: RAM,runtime

  Multiplicity: [0,1]

• help

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Help text for the displayed item. Help text is usually displayed when the user clicks on help/information icon. This may be a longer text (several sentences).

  This is equivalent to "help" schema annotation and can be used to override it.

• description

  Flags: RAM,runtime

  Multiplicity: [0,1]

• documentation

  Flags: RAM,runtime

  Multiplicity: [0,1]

• displayOrder

  Flags: RAM,runtime

  Multiplicity: [0,1]

• limitations

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Limits the usage of the attribute, e.g. whether it may is read-only, read write or entirely ignored. The limitations may apply to several system layers, therefore this element may be repeated several times. But it there may be only one instance for each layer.

• matchingRule

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Specification of a matching rule for an attribute. Matching rule is used to compare values of the attribute. The default rule is a literal comparison which is good for most attribute types and for case-sensitive strings. An alternative matching rule may be specified e.g. for case insensitive strings.

• 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]

  When set to true, allows attribute/property values that are set outside midPoint (or outside object template mappings). The synchronization will only remove values that are assigned by midPoint (or template mappings), but will tolerate extra native values. When set to false, extra values are not tolerated. When midPoint detects such value (e.g. during reconciliation) it will remove it. Support of non-tolerant items in object templates is currently EXPERIMENTAL.

• tolerantValuePattern

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Pattern (regexp) for attribute/property value. If the value matches the pattern such value is tolerated. It is left in the attribute/property even if it is not derived from any mapping. This element is currently supported only in resource object type definitions. Support in object templates is planned.

• intolerantValuePattern

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Pattern (regexp) for attribute/property value. If the value matches the pattern such value is NOT tolerated. The value must be derived from a mapping or it will be removed. This element is currently supported only in resource object type definitions. Support in object templates is planned.

• 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.

• validation

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Validation rules for the item. Validation rule may be applied in the user interface. But server-side validation may also be applied during the computation process.

• persistence

  Flags: RAM,runtime,AVals:3

  Multiplicity: [0,1]

  Whether values of this item should be persisted. Currently implemented for metadata only.

• exclusiveStrong

  Flags: RAM,runtime

  Multiplicity: [0,1]

  When set to false then both strong and normal mapping values are merged to produce the final set of values. When set to true only strong values are used if there is at least one strong mapping. Normal values are used if there is no strong mapping.

• modificationPriority

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Modification priority of this item. Items with specified priorities are modified in order that follows these priorities: these with lower numbers are modified first, these with higher numbers next, and items with unspecified priorities are modified last. Each priority level gets its own modify operation (or operations, if required by ICF limitations). Currently this field is supported only for attributes, even it is present on associations as well. (It is envisioned that 'addingPriority' could be created as well in the future; it would concern creating new objects. In that case, attributes with numerically lowest adding priority would be used to create an object, and other attributes would be set via MODIFY operation, again, according to their priorities.)

• readReplaceMode

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Modifications to this attribute are executed in REPLACE form only. I.e. if ADD or DELETE VALUE is requested, midPoint will fetch the object state, compute the expected result and write it to the resource object via REPLACE VALUE operation. This works around some weird connector behavior. BEWARE: READ+REPLACE is currently supported for attributes only - not for subjectToObject associations. EXPERIMENTAL. May change in near future.

• secondaryIdentifier

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Indicated if the attribute should be considered as secondary identifier. If set to true, this attribute is stored in repository and used for example by synchronization (correlation rule), consistency mechanism, etc.

• 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]

  Indicated if the content of this attribute should be used as a human-readable name when displaying resource objects of this type.

• fetchStrategy

  Flags: RAM,runtime,AVals:3

  Multiplicity: [0,1]

• storageStrategy

  Flags: RAM,runtime,AVals:2

  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.