ResourceObjectTypeDefinitionType (Complex Type)

Items

• kind

  Flags: RAM,runtime,AVals:4

  Multiplicity: [0,1]

• intent

  Flags: RAM,runtime

  Multiplicity: [0,1]

• displayName

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Human readable name. This name may be displayed in tools and GUIs to provide more pleasant user experience, as the XML data type names or object names may look quite frightening.

  The "displayName" should contain a value that is readable for almost any user. It is never used in the "logic", it is used only for display purposes.

  The use of national characters is in "displayName" is fully supported.

  DisplayName is reused in several location, but the meaning is still the same.

• description

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Free-form textual description of the object. It is supposed to describe the object or a construct that it is attached to.

  This information may be presented to midPoint users, even to ordinary end users. For example role description may be presented to users when they are selecting roles to request. Therefore the description should be written in a language that the users can understand.

  Description is assumed to be a plan, non-formatted text. Amount of white space is considered insignificant. E.g. leading and trailing white space may be skipped, multiple spaces can be collapsed to one and so on.

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

• default

  Flags: RAM,runtime

  Multiplicity: [0,1]

  Specifies whether this type is the default type for the resource. Only one type for each class can be default. Setting this flag to true for more than one type is an error. If the flag is not set, the value is inherited from resource schema. If the resource schema does not have this flag set, the default value is false.

• objectClass

  Flags: RAM,runtime

  Multiplicity: [1,1]

  XSD type from the resource schema (Object Class) that should be used for accounts on this resource.

• auxiliaryObjectClass

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  The reference to additional type definitions 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.

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

  TODO

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

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

• attribute

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Specification of handling of an account attribute. This overrides annotations in the resource schema.

• dependency

  Flags: RAM,runtime

  Multiplicity: [0,-1]

• association

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Describes how entitlement is associated to the subject (e.g. account or other entitlement). Description of the entitlement handling details, such as display name, read/write access and so on. This is supposed to be used in schemaHandling part and in assignments/inducements and therefore it describes the decisions of the system administrator about the way how entitlements are used in midPoint.

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

• protected

  Flags: RAM,runtime

  Multiplicity: [0,-1]

  Specification of a protected account: account that cannot be affected by IDM. It will be ignored by operations, will not appear in lists, etc.

• 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: dyn,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 of the 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.