ResourceObjectAssociationType (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]

  Technical documentation for a particular object or construct.

  The purpose of this element is to document system configuration and behavior. The documentation will not be presented to end users. In fact, it will probably not be presented at all in midPoint user interface. This documentation element is supposed to be a part of the technical documentation of midPoint deployment. The tools than generate deployment configuration will look for these elements and combine them to compiled documentation document.

  AsciiDoc formatting is assumed for this element. Any leading or trailing whitespace is skipped. Indentation equivalent to he indentation of the first non-blank line of text is also skipped.

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

• auxiliaryObjectClass

  Flags: RAM,runtime

  Multiplicity: [0,1]

  This association is considered valid only if the resource object (subject) has the specified auxiliary object class.

• kind

  Flags: RAM,runtime,AVals:4

  Multiplicity: [0,1]

• intent

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  A set of intents corresponding to this association type. NOTE: All of them must point to the same resource ObjectClass! The association may point to many intents (many object types with different intents). This is sometimes useful, especially if there are many types of groups and each type is constructed in a slightly different way. The multi-intent associations are supported and often very useful. But there is an important hard limitation: all the object types referenced from a single association must have the same object type, attributes, matching rules, .... they must be equivalent in every aspect except for attribute mappings.

• direction

  Flags: RAM,runtime,AVals:2

  Multiplicity: [0,1]

  Specifies the direction of association, i.e. if the association point from object to subject or the other way around.

• associationAttribute

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Name of the attribute which represents the association. This is the attribute that will be modifier when the association changes. In object-to-subject associations this is the attribute of the object (e.g. group). In subject-to-object associations this is an attribute of the subject (e.g. account). Typical examples are: roles, privileges, member, uniqueMember

• valueAttribute

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Name of the attribute from with a value for association attribute is taken. The value is taken from this attribute and it will be stored in the association attribute. This attribute will NOT be modifier when the association changes, it is only for reading. In object-to-subject associations this is the attribute of the subject (e.g. account). In subject-to-object associations this is an attribute of the object (e.g. group). This attribute usually contain identifiers. Typical examples are: name, username, uid, id

• shortcutAssociationAttribute

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Association attribute short-cut. There are cases when a object-to-subject association is the authoritative one, but reading object-to-subject is expensive. E.g. several searches must be done to fully resolve object-to-subject associations. This attribute provides a short-cut mechanism. It is used in cases when there is additional (virtual) attribute that goes in the opposite direction as the primary object-to-subject association attribute. The association short-cut is only usable for object-to-subject associations. This property specifies name of the attribute which represents the association short-cut. This is the attribute of the subject (e.g. account). This attribute will only be read, it is never written. The primary association attribute is used for writing. Typical examples are: memberOf, isMemberOf

• shortcutValueAttribute

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Association attribute short-cut. There are cases when a object-to-subject association is the authoritative one, but reading object-to-subject is expensive. E.g. several searches must be done to fully resolve object-to-subject associations. This attribute provides a short-cut mechanism. It is used in cases when there is additional (virtual) attribute that goes in the opposite direction as the primary object-to-subject association attribute. The association short-cut is only usable for object-to-subject associations. This property specifies name of the attribute from with a value for association attribute short-cut is taken. The values of this attribute are expected to appear in association short-cut attribute. This is an attribute of the object (e.g. group). This attribute usually contain identifiers. Typical examples are: name, username, uid, id

• explicitReferentialIntegrity

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Whether you require midPoint to provide referential integrity for object-to-subject associations. Used for resources that do not provide referential integrity by themselves, e.g. for OpenDJ with default settings (i.e. with referential integrity plugin turned off). For resources having referential integrity, e.g. for Active Directory, set this parameter to false.