<objectType>
<!-- no kind nor intent specified --> (1) (2)
<displayName>Default account</displayName>
<defaultForKind>true</defaultForKind>
<!-- ... -->
</objectType>
<objectType>
<kind>account</kind>
<intent>testing</intent>
<displayName>Testing account</displayName>
<!-- ... -->
</objectType>
<objectType>
<kind>entitlement</kind>
<intent>group</intent>
<displayName>Standard group</displayName>
<defaultForKind>true</defaultForKind>
<!-- ... -->
</objectType>
<objectType>
<kind>entitlement</kind>
<intent>other</intent>
<displayName>Some other entitlement</displayName>
<!-- ... -->
</objectType>Defaults
"Default for Kind" Property
This property specifies whether the given resource object type is the default one for given kind of objects, i.e. for accounts, entitlements or "generic objects".
Only a single type can be the default one for given kind.
Setting this flag to true for more than one type is an error.
There are two specific places where this is used.
Resource Object Construction
When a resource object construction is assigned to a focus object (for example, to a user), there are the following defaults:
-
if kind is not specified, the account is assumed;
-
if intent is not specified, the "default for kind" intent is assumed - for the given kind.
Search for Resource Objects
There are situations when midPoint searches for resource objects.
The most prominent are searches done as part of import or reconciliation activities.
The use of projectionDiscriminator in associationFromLink results in a search operation as well.
(See sample constructions below.)
When searching for resource objects without providing object class name, the following applies:
-
kind must be specified;
-
if intent is not specified, the "default for kind" intent is assumed - for the given kind.
See also Resource Object Set Specification.
An Example
Let us have the following configuration of object types:
Sample configuration
| 1 | If kind is not specified in the definition, account is assumed. |
| 2 | If intent is not specified in the definition, default (literally) is assumed. |
Sample resource object constructions
<role xmlns="http://midpoint.evolveum.com/xml/ns/public/common/common-3">
<!-- ... -->
<assignment>
<construction>
<resourceRef oid="0e5b7304-ea5c-438e-84d1-2b0ce40517ce"/>
<kind>entitlement</kind>
<!-- no intent specified --> (1)
</construction>
</assignment>
<inducement>
<construction>
<resourceRef oid="0e5b7304-ea5c-438e-84d1-2b0ce40517ce"/>
<!-- no kind nor intent specified --> (2)
<association>
<ref>ri:groups</ref>
<outbound>
<expression>
<associationFromLink>
<projectionDiscriminator>
<kind>entitlement</kind>
<!-- no intent specified --> (3)
</projectionDiscriminator>
</associationFromLink>
</expression>
</outbound>
</association>
</construction>
</inducement>
</role>| 1 | group intent is assumed, as it is marked as "default for kind" for entitlements (see Resource Object Construction) |
| 2 | account kind is assumed, and within it, default intent, as it is marked as "default for kind" for accounts (see Resource Object Construction) |
| 3 | group intent is assumed, as it is marked as "default for kind" for entitlements, and we are doing a search for entitlements here (see Search for Resource Objects) |
"Default for Object Class" Property
This property specifies whether the given resource object type is the default one for its object class, e.g. for ri:AccountObjectClass or ri:inetOrgPerson.
Only a single type can be the default one for given object class.
Setting this flag to true for more than one type is an error.
There are two specific places where this is used.
Classifying the Resource Objects
When classifying resource objects, we often use the type marked as "default for object class" as a "catch-all" type when no other type matches.
However, this functionality can be achieved - perhaps more cleanly - also using classificationOrder property of object type delineation.
See the classification algorithm description.
Looking for Default Definitions
This applies when searching for resource objects, typically in import or reconciliation activities, and using only the object class name. For example:
Importing accounts by object class name
<task>
<!-- ... -->
<activity>
<work>
<import>
<resourceObjects>
<resourceRef oid="2696334a-c3d1-4aa6-b147-ff16cd387a0f"/>
<objectclass>ri:inetOrgPerson</objectclass>
</resourceObjects>
</import>
</work>
</activity>
</task>There are definitions that should be applied when the query against the resource (looking for all inetOrgPerson objects) is issued.
For example, midPoint needs to specify attributes to return or the base context.
When defaultForObjectClass is used in a type definition that refers to inetOrgPerson class, that type definition is used to provide the necessary information.
(Note that midPoint still attempts to synchronize all members of inetOrgPerson.)
However, since 4.6, the preferred way to provide such object-class-level definitions that should be applicable to all objects of given object class
(e.g. inetOrgPerson) is to use Object Class Definition Adaptation, i.e. to provide schemaHandling/objectClass refinement for ri:inetOrgPerson.
Therefore, it’s no longer necessary nor recommended to specify default object type for object class just for this purpose.
Overall, it is better to avoid defaultForObjectClass setting, and hence also default setting.
"Default" Property
This is a shorthand for specifying both defaultForKind and defaultForObjectClass.
These three properties, defaultForKind, defaultForObjectClass and default, may be changed or even removed in the future.
Was this page helpful?
YES
NO
Thanks for your feedback