ResourceObjectTypeDefinitionType (Complex Type)

Items

• kind

  Flags: RAM,runtime,AVals:4

  Multiplicity: [0,1]

  Kind of objects covered by this type. For object class refinements, it must not be specified (and the default does not apply there as well).

• intent

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Intent of objects covered by this type. For object class refinements, it must not be specified (and the default does not apply there as well).

• displayName

  Flags: RAM,runtime

  Multiplicity: [0,1]

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

• lifecycleState

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Lifecycle state of the object class or object type. First, it drives the visibility of the configuration for production-like or simulation tasks. Second, it influences the behavior of specific provisioning operations (like shadow classification). The lifecycle state is propagated downwards, from the level of a resource, down to the level of an object class, and finally to the level of an object type. If the state is evaluated as "non-matching" at a given level, all lower levels are ignored. For example, if an object class has a "proposed" lifecycle state, all its object types are considered to be in non-production development state, regardless of their own lifecycle state values.

• abstract

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Is this an abstract object type? Such a type cannot be referenced from a construction, nor it can be used as a categorization result. It is also not referencable from e.g. search queries.

• super

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Super type of this resource object type. For object class refinements, it must not be specified.

• default

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Specifies whether this resource object type is the default one that is used when: 1. Kind without intent is specified (e.g. in assigned construction or in synchronization task). 2. Object class without kind/intent is specified (e.g. in synchronization task). Technically, setting a value for this property is propagated to both "defaultForKind" and "defaultForObjectClass" ones. See their documentation for more information.

• defaultForKind

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Specifies whether this resource object type is the default one for given kind of objects, i.e. for accounts, entitlements or "generic objects". This means that if e.g. object type T is specified with kind=account and defaultForKind=true, and a resource object construction is assigned with kind=account (without providing an intent), then this object type (T) is being assigned as a result. In a similar way, if a synchronization activity (like import or reconciliation) is specified with kind=account (without providing an intent), then the synchronization proceeds against objects of this type T. (I.e. NOT against all objects with kind=account!) Only one type can be the default one for given kind. Setting this flag to true for more than one type is an error.

• defaultForObjectClass

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Specifies whether this resource object type is the default one for the given object class, e.g. for ri:AccountObjectClass or ri:inetOrgPerson. This means that if e.g. given object type T is specified with objectClass=ri:inetOrgPerson and defaultForObjectClass=true, and a synchronization task is started for object class of ri:inetOrgPerson (without providing kind/intent), the definition to be used when issuing the query - e.g. attributes to return, base context, and so on - is derived from the definition of this object type T. (Note that midPoint still attempts to synchronize all members of the said object class, if only the object class is specified in the synchronization task.) Since 4.6, the preferred way to provide such object-class-level definitions is to use so-called refined object class definitions, i.e. to provide schemaHandling/objectClass refinement for ri:inetOrgPerson. Therefore, it's no longer necessary to specify default object type for object class just for this purpose. Another use of this flag is to specify the default type for classification of resource objects of given object class. But this functionality can be achieved also using "classificationOrder" property of object type delineation. Only one type can be the default one for given object class. Setting this flag to true for more than one type is an error.

• objectClass

  Flags: RAM,runtime

  Multiplicity: [0,1]

  For object type definition: Object class (like ri:inetOrgPerson) for this resource object type. MOVED TO "delineation". For refined object class definition: Name of object class (like ri:inetOrgPerson) that is refined by this definition. In this case, this property should be used here, not in "delineation" definition.

• auxiliaryObjectClass

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  For object type definition: The reference to additional object classes for this object. The reference should point to object class definition (complex type definition in resource schema) and this definition should be marked as auxiliary. DEPRECATED. MOVED TO "delineation". For object class definition: Should not be used at all.

• auxiliaryObjectClassMappings

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Outbound/inbound mappings for auxiliary object classes. These can be used to manipulate auxiliary object classes beyond the simple capabilities provided by the auxiliaryObjectClass property.

  NOTE: outbound mapping for auxiliary object classes is not yet supported.

  If tolerant flag is set to true then midPoint will tolerate existing auxiliary object classes on resource objects. MidPoint will add/remove auxiliary object classes only if there is an explicit operation for that (e.g. assign/unassign of role with auxiliary object class definition). If tolerant flag set to false then midPoint will strictly synchronize auxiliary object classes of resource objects with the definition given in midPoint configuration. This is the default behavior.

  NOTE: the "tolerant" behavior is disabled by default for auxiliary object classes. This is different for most other midPoint definitions where tolerant behavior is enabled by default. This inconsistency has historic (compatibility) reasons. But having auxiliary object classes non-tolerant also makes a lot of sense in usual situations.

• multiplicity

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Describes how "multi-accounts" are treated for this object type.

• delineation

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Delineates (defines) the set of objects corresponding to this object type, e.g. by providing object class(es), a base context and/or a search filter.

• baseContext

  Flags: RAM,runtime

  Multiplicity: [0,1]

  The definition of base context (resource object container). This object will be used as a base for searches for objects of this type. Usually only the objects that are hierarchically below the baseContext are returned by such a search. E.g. this is used to specify LDAP organizationalUnit that contains users or groups of particular type. DEPRECATED: set the value in "delineation" instead

• searchHierarchyScope

  Flags: RAM,runtime,AVals:2

  Multiplicity: [0,1]

  Definition of search hierarchy scope. It specifies how "deep" the search should go into the object hierarchy. It is only applicable to resources that support hierarchical organization of objects (e.g. LDAP resources). DEPRECATED: set the value in delineation instead

• focus

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Type and archetype (optional) of the focus objects that correspond to this resource object type. If not specified (neither here nor in legacy synchronization configuration), the UserType is assumed.

• provenance

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Specifies provenance properties that should be associated with data that originate here. Resource objects of the type that is defined here will be assumed to have the provenance specified in this data structure.

• attribute

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Specification of handling of resource object attributes. This overrides annotations in the resource schema.

• dependency

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Specification of dependencies of this object type on other type or types.

• association

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Specification of associations for this object types. Associations do not always have the same physical manifestation as attributes, i.e. they are not always directly visible on the raw resource object. They may be represented implicitly e.g. in the form of group membership.

• volatility

  Flags: RAM,runtime,AVals:3

  Multiplicity: [0,1]

  Specifies volatility of this type of resource objects, i.e. whether it can change when midPoint is not looking. (Meaning if it is possible that midPoint creates or updates the object, providing some attributes, but after subsequent read, some relevant attributes would have values other than provided.) An example of volatile object is Exchange mailbox, where its PrimarySmtpAddress (or EmailAddresses) can be created based on system policies. Therefore, in order to fill-in $user/emailAddress based on PrimarySmtpAddress, one has to fetch a newly created object before applying inbound mappings. Set this property only if you really need to execute inbounds on volatile attributes; otherwise you'll get performance penalty with no benefits in return.

• iteration

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Definition of an iteration process where the unique identifier (e.g. a name) of the resource object is determined iteratively: taking the first "available" value. Like trying smith1, smith2, and so on; until the unused one is found.

• protected

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Specification of a protected resource object: one that cannot be affected by IDM. It will be ignored by operations, will not appear in lists, etc. A typical example is the administrator's account.

• activation

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Definition of activation handling for this account type.

• credentials

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Definition of credentials handling for this account type.

• securityPolicyRef

  Flags: RAM

  Multiplicity: [0,1]

  Reference to the object type security policy settings.

• lifecycle

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Definition of resource object lifecycle handling. It defines how the initial lifecycle state is determined, constraints for lifecycle transitions, etc.

• configuredCapabilities

  Flags: RAM,runtime

  Multiplicity: [0,1]

  The configured capabilities of the resource specific to this object type. This part contains "tweaks" of the native capabilities. Some native capabilities may be turned off, other capabilities may be simulated. If this element is not present at all then the native+configured capabilities at the resource level are applied.

• projection

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Object type related account synchronization settings.

• mappingsEvaluation

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Settings related to evaluation of mappings for this object type.

• correlation

  Flags: RAM,runtime

  Multiplicity: [0,1]

  How objects of this type are correlated to focus objects?

• synchronization

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Defines reactions to specific synchronization-related situations (like "unmatched resource object", or "disputed" (owner), and so on. Before 4.6, this information was part of the "synchronization" section of the resource definition.