Archetype Configuration

Last modified 21 Nov 2025 09:13 +01:00
Archetype feature
This page describes configuration of Archetype midPoint feature. Please see the feature page for more details.
Table of Contents

This page describes how to define archetypes in midPoint, including their icons, assignment relations, and inheritance, as well as the pre-defined archetypes.

Introduction

Archetype is a well-defined object subtype. Employee, Contractor, Project, Workgroup, or Application can be archetypes for various classes of objects based on their character.

See Archetypes for a more in-depth introduction to the archetype concept.

Refer to Archetype Configuration in GUI for the midPoint graphical user interface guide on the topic.

Archetype definition

Archetype definitions are special midPoint objects (ArchetypeType).

Archetypes define the character and behavior of "archetyped" objects in the archetypePolicy section. The archetype definition example below specifies what icons, color and labels to use, which templates to apply, and so on.

Example of an archetype definition
<archetype oid="7135e68c-ee53-11e8-8025-170b77da3fd6">
   <name>employee</name>
   ...
   <archetypePolicy>
       <!-- definition of archetype icon, color and labels will be here -->
   </archetypePolicy>
   ...
</archetype>

Archetypes work like abstract roles, therefore all objects that need to be "archetyped" can be assigned to an archetype.

Being midPoint objects, archetypes have natural persistent identifiers: OID. The OID of the an archetype definition is also an archetype identifier. Each object of that archetype will contain an archetype definition OID in the archetypeRef reference.
For example, every employee will contain an OID of an employee archetype definition object. This OID is used internally by midPoint to process archetypes. But it can also be used for searching objects of particular archetypes by a custom code or midPoint API clients.

Example of a user object with an archetype assignment
<user>
   <name>foo</name>
   <archetypeRef oid="7135e68c-ee53-11e8-8025-170b77da3fd6" /> <!-- "employee" archetype -->
   ...
   <assignment>
       <targetRef oid="83614aaa-ee57-11e8-b770-7f3cb1d00719" type="RoleType"/> <!-- some role, that includes another role, that includes "employee" archetype -->
   </assignment>
</user>

In the example above, a user was created with an archetype assignment, but without the archetypeRef reference. The archetypeRef reference is computed by midPoint and stored in the object. This reference is needed for an easy and efficient resolution of an archetype because archetypes may be assigned indirectly. The archetypeRef reference can also be used to search for all objects of a given archetype.

Archetypes as abstract roles

Archetype definitions are abstract roles which means they essentially work as roles. To apply an archetype to an object, assign the archetype to that object as you would normally assign a role. Once assigned, the archetype applies to that object. Being abstract roles, archetypes are really powerful.

Archetypes may work as ordinary roles or metaroles:

Example of an archetype used as a metarole
<archetype oid="7135e68c-ee53-11e8-8025-170b77da3fd6">
   <name>employee</name>
   ...
   <inducement>
       <!-- whatever roles, rules and privileges that an employee needs to have -->
   </inducement>
</archetype>

Because archetypes are abstract roles, they may also be assigned indirectly. For example, a basic employee role may contain an inducement for an employee archetype, making sure that all holders of the basic employee role will have an appropriate archetype.

Icons, colors, and labels

Archetype policies can be used to set custom icons, colors and labels for "archetyped" objects.

The example below sets a custom icon for the employee archetype. It also specifies that whenever an employee icon can be used in color, then the blue color should be used. There is also a label that should be used to display objects of that particular archetype; and also a plural form of the label used when objects of that archetype are listed.

Example of setting a custom icon, color and labels for an archetype
<archetype oid="7135e68c-ee53-11e8-8025-170b77da3fd6">
   <name>employee</name>
   ...
   <archetypePolicy>
        <display>
            <label>Employee</label>
            <pluralLabel>Employees</pluralLabel>
            <icon>
                <cssClass>fa fa-user</cssClass>
                <color>blue</color>
            </icon>
        </display>
    </archetypePolicy>
    ...
</archetype>

Archetypes and views

If an archetype is assigned to an object, midPoint honors that archetype definition. For example, it will display those objects with the appropriate icon and color. But otherwise, archetype definitions and object lists are not displayed in the user interface by default - except for places such as Repository Objects. This behavior has several reasons: there may be archetype definitions that are just being prepared, definitions that should not be publicly visible, or there may be just too many definitions to be displayed in the menu. Therefore, by default, there will be no additional menu items or "shortcut" buttons for archetypes.

Archetypes can be added to menus and other places of midPoint interface by using object views. All that is needed is a simple definition of a view in the admin GUI configuration structure similar to the following:

Example of defining an object collection view for an archetype
...
<adminGuiConfiguration>
    <objectCollectionViews>
        <objectCollectionView>
            <identifier>empls-view</identifier>
            <type>UserType</type>
            <collection>
                <collectionRef oid="7135e68c-ee53-11e8-8025-170b77da3fd6" type="ArchetypeType"/> <!-- "employee" archetype -->
            </collection>
        </objectCollectionView>
    </objectCollectionViews>
</adminGuiConfiguration>
...

This can be defined in the global system configuration or in a role. Such view should create an "Employees" link in the "Users" section of the main menu.

The view specifies a means of displaying a collection of objects. Creating an appropriate menu item is just one of the aspects. The view may also define what the actual list of objects looks like. The view specifies the columns, defaults search settings, and so on. However, when the view is bound to an archetype, it can do even more - it can automatically render buttons to create new objects.

Assignment relation

Archetypes can define possible object types and relations that can be used in assignments to "archetyped" objects, e.g.:

  • Projects are organizational units that can have members, managers and owners.

  • Business roles have members, owners and approvers. Owners and approvers must be employees.

  • Departments are organizational units that may contain other organizational units (but only if they are of the Section archetype), users, and business roles.

There is an assignment relation mechanism that can be used for that purpose. The assignment relation specification can be used to limit possible assignment holder object types and assignment relations. This is perhaps best illustrated using an example of a business role:

Example of assignment relations for a business role archetype
<archetype oid="018e7340-199a-11e9-ad93-2b136d1c7ecf">
    <name>Business Role</name>
    ...
    <inducement>
        <assignmentRelation>
            <description>Any user can have business role (can be a member).</description>
            <holderType>UserType</holderType>
            <relation>org:default</relation>
        </assignmentRelation>
        <assignmentRelation>
            <description>Only employees may be owners/approvers for business role.</description>
            <holderType>UserType</holderType>
            <holderArchetypeRef oid="7135e68c-ee53-11e8-8025-170b77da3fd6"/> <!-- Employee archetype -->
            <relation>org:approver</relation>
            <relation>org:owner</relation>
        </assignmentRelation>
    </inducement>
    ...
</archetype>

In the example above, assignmentRelation specifies that any user can be assigned to the business role with the default relation. Also, it specifies rules for the approver and owner relations. Only an employee can be the owner or approver of the business role.

Note that in this case, assignmentRelation specifications are placed in an inducement of the archetype, not assignment. We want to apply assignmentRelation to "archetyped" objects. And that is exactly what inducements do.

But archetype definitions are first-class midPoint objects, and they are also abstract roles. An archetype definition can have assignments pointing to it, such as an owner of an archetype definition. The assignmentRelation statements in the assignment would also make sense if we wanted to control what objects can be assigned to the archetype definition. However, assignmentRelation is typically placed in an inducement.

Open and closed assignment relations

Assignment relation specifies which objects can be assigned to other objects. But how to interpret a situation when there is no assignment relation specified? This can mean two different things:

  • Open approach: No assignment relation is used. Any assignments to any objects are possible. The user interface will render a button that allows assigning any combination of a target object and relation. This is the default behavior.

  • Closed approach: No assignment relations are possible. Only relations that are explicitly specified should be allowed. This option is ideal for systems that have a finished and cleaned up archetype configuration.

The user interface will always render buttons that allow assigning of specific object types given by the assignment relation. E.g., a button to "assign a business role" will always be there (assuming that there is a "business role" archetype with appropriate assignmentRelation). The difference between open and closed approach is that in the open mode, the "generic" assignment button will be rendered in addition to other buttons.

The open/closed approach can be specified in an archetype policy. In the configuration below, whenever an employee is edited in the midPoint user interface, the "generic" assignment button is not rendered. Only the buttons given by an explicit assignmentRelations definition are rendered.

Example of setting closed assignment relation approach for an archetype
<archetype oid="7135e68c-ee53-11e8-8025-170b77da3fd6">
   <name>employee</name>
   ...
   <archetypePolicy>
        ...
        <assignmentHolderRelationApproach>closed</assignmentHolderRelationApproach>
        ...
    </archetypePolicy>
    ...
</archetype>

Both open and closed mode are still limited by authorizations, of course.

This setting controls the behavior of the midPoint user interface. E.g., setting the approach to "closed" will hide the button that controls generic assignment in the "Assignments" tab for individual users. But it will not disable a similar button in the "Members" tab for roles. This setting only controls the uni-directional behavior of GUI. It does not constraint the entire assignment model. That would be too complex to implement (at least for now).

The assignmentHolderRelationApproach controls the "holder" side of the relation. A similar property that can limit the "target" side of the relation (e.g. buttons in the "Members" tab) is planned for the future.

Currently, this can be configured only on per-archetype basis. There is no global setting that can set open/close as the default for the entire system. The plan is to implement this later together with "inheritance" of object policy configurations in system configuration objects. E.g., an object policy for UserType inheriting from an object policy for ObjectType - and user archetypes inheriting from the UserType policy.

Order constraints

Assignment relation applies only to assignments by default. Therefore, it controls when an assignment can be made. It does not apply to inducements (yet). In later midPoint versions, there will be an element that can specify "order constraints" that will enable assignment relations to specify properties of inducements, including high-order inducements. However, the current implementation is limited to assignments.

Default definition

While archetype definitions can specify behavior details for "archetyped" objects, there are also objects that do not have any archetype. And you may want to control the behavior of those objects as well. In fact, this has been possible in midPoint for a long time, even though it was not explicitly denoted as having anything to do with archetypes.

There is the defaultObjectPolicyConfiguration container in the system configuration object.
Its data structure is almost identical to the structure of archetypePolicy in the archetype definition, and it works in almost the same way.
This is the definition that is applied to non-archetyped objects of that particular type. Parts of that definition may also apply to archetyped objects, as this definition is merged with archetypePolicy.
Even though archetypePolicy will override any aspects of the default specification, the aspects that are not defined in archetypePolicy are taken from the default global policy.

An example default object policy configuration
<systemConfiguration>
   ...
   <defaultObjectPolicyConfiguration>
      <type>UserType</type>
      <objectTemplateRef oid="10000000-0000-0000-0000-000000000222"/>
   </defaultObjectPolicyConfiguration>
   ...
</systemConfiguration>

Pre-Defined archetypes

MidPoint is designed to fit in many environments and those environments may differ significantly. However, there are still a few aspects that most of the environments have in common. There are types of objects that are used in almost any midPoint deployment. Therefore, midPoint has several default archetypes that can be used as a starting point for further midPoint configurations

Table 1. Pre-defined archetypes in midPoint
Archetype Member Object Type Member Objects Description

System User

User

administrator

Archetype for system users, i.e., non-person users that are needed for the system to work. This may be a (root-like) system administrator, application users, and so on.

Person

User

none

Archetype for persons which is used in First Steps Methodology.

System Role

Role

superuser, approver, reviewer, delegator

Archetype for roles that are essential from the system point of view. Those are usually roles for the most powerful system administrators, roles for internal usage in the system (e.g., by tasks), and so on.

Business Role

Role

none

Archetype for roles that are significant from the business perspective. Business roles are usually assigned directly to users, often by using request-and-approve processes. Business roles are usually composed from smaller roles.

Manual Provisioning Case

Case

none, assigned dynamically

Archetype for cases that describe manual provisioning operations.

Operation Request

Case

none, assigned dynamically

Archetype for cases that describe operation requests, e.g., role assignment requests.

Approval Case

Case

none, assigned dynamically

Archetype for approval cases, e.g., role assignment approval.

Some of the archetypes are provided as a starting point for the system configuration. This is namely the Business Role archetype.

You can modify the pre-defined archetypes. They are provided in the initial objects mostly to keep the terminology of midPoint deployments aligned, and to make communication in the midPoint community smoother.

There are also archetypes that are essential for midPoint functionality, e.g., the archetypes for cases. While you can still modify those, you should have a good understanding of how midPoint works and what effects can those changes may have.

Authorizations

Archetypes can be used as criterions in authorizations:

Archetype used as a criterion in an authorization
  <authorization>
    <action>...</action>
    <object>
      <archetypeRef oid="00000000-0000-0000-0000-000000000321"/>
    </object>
  </authorization>

Multiple archetypes

MidPoint archetypes are strongly inspired by how LDAP objectClasses can be defined and used. Therefore, midPoint is designed to support the following kinds of archetypes:

  • Structural

    • These represent the main class/type of an object (e.g., Person, Service account, Application) and define its properties (including visuals), behavior, birthrights, and so on.

    • They are expected to be practically static during the lifetime of an object. Typically, the object is created with a structural archetype and keeps it forever.

    • Only one structural archetype can be assigned to an object directly.

    • They can be extended, and they can extend other structural or abstract archetypes.

  • Auxiliary

    • An auxiliary archetype can be assigned to an object with a structural archetype assigned. Objects can have more than one auxiliary archetypes assigned.

    • Enables you to model multiple dynamic situations and complement the main (structural) archetype. For example, if the structural archetype is Person, auxiliary archetypes can be Employee, Customer, Student, Volunteer, and so on.

  • Abstract (not yet supported)

    • Cannot be assigned directly to an object, can be extended, can extend another abstract archetype.

Configuration is done using the archetypeType property that should not be changed if the archetype is already used. The default value is structural.

Archetype type configuration example
<archetype>
    ...
    <archetypeType>auxiliary</archetypeType>
    ....
</archetype>

Archetype inheritance

It is possible to define a hierarchy between structural archetypes. This means you can extend an archetype by its children. To define archetype inheritance, you need to point the child archetype to its parent using the superArchetypeRef element, such as in the example below:

Archetype inheritance
<archetype>
    ...
    <superArchetypeRef oid="00000000-0000-0000-0000-000000000521" type="ArchetypeType"/>
    ....
</archetype>

The following practices apply when using archetype inheritance:

  • For basic archetype attributes, such as name, or displayName- Attributes defined in the archetype assigned directly to the object are used.

  • For archetypePolicy - All archetype policies defined either in the directly assigned archetype, or in super (higher-level) archetypes, are merged together.

  • For inducements and assignments - These are applied based on the standard midPoint algorithms. Note that the inheritance relation defined by superArchetypeRef is translated to the inducement as well. In other words, the example above is translated to an inducement with the target oid="00000000-0000-0000-0000-000000000521" when evaluating assignments/inducements.

Archetype policy - merging

There is quite a complex algorithm for merging archetype policies across hierarchies. The following examples show you how the merging works.

The first example below shows an archetype for a basic task. It contains an archetype policy defining what the icon should look like, and two GUI virtual containers (sections) used on the task details page: Advanced options and Operational attributes (state).

Basic task
{
  "@ns" : "http://midpoint.evolveum.com/xml/ns/public/common/common-3",
  "archetype" : {
    "name" : "Basic task",
    "archetypePolicy" : {
      "display" : {
        "label" : "Task",
        "pluralLabel" : "Tasks",
        "icon" : {
          "cssClass" : "fa fa-tasks",
          "color" : "grey"
        }
      },
      "adminGuiConfiguration" : {
        "objectDetails" : {
          "type" : "http://midpoint.evolveum.com/xml/ns/public/common/common-3#TaskType",
          "container" : [ {
            "display" : {
              "label" : "Advanced options"
            },
            "displayOrder" : 150,
            "item" : [ {
              "path" : "cleanupAfterCompletion"
            }, {
              "path" : "threadStopAction"
            }, {
              "path" : "binding"
            }, {
              "path" : "dependent"
            } ]
          }, {
            "display" : {
              "label" : "Operational attributes (state)"
            },
            "displayOrder" : 900,
            "item" : [ {
              "path" : "executionStatus"
            }, {
              "path" : "node"
            }, {
              "path" : "nodeAsObserved"
            }, {
              "path" : "resultStatus"
            }... ]
          } ]
        }
      }
    }
  }
}

The following archetype example extends the basic task archetype above. It is a parent archetype for resource related tasks, containing additional information about icon color, attributes which have to be hidden/shown on the details page, and some additional information for GUI virtual containers (sections) on the details page.

Resource related task (extends basic task)
{
  "@ns" : "http://midpoint.evolveum.com/xml/ns/public/common/common-3",
  "archetype" : {
    "name" : "Resource related task",
     ....
    "archetypePolicy" : {
      "display" : {
        "icon" : {
          "color" : "green"
        }
      },
      "itemConstraint" : [ {
        "path" : "extension",
        "visibility" : "vacant"
      }, {
        "path" : "declare namespace mext='http://midpoint.evolveum.com/xml/ns/public/model/extension-3'; extension/mext:objectclass",
        "visibility" : "visible"
      }, {
        "path" : "declare namespace mext='http://midpoint.evolveum.com/xml/ns/public/model/extension-3'; extension/mext:kind",
        "visibility" : "visible"
      }.... ],
      "adminGuiConfiguration" : {
        "objectDetails" : {
          "type" : "http://midpoint.evolveum.com/xml/ns/public/common/common-3#TaskType",
          "container" : [ {
            "identifier" : "resourceOptions",
            "display" : {
              "label" : "resourceObjects"
            },
            "item" : [ {
              "path" : "objectRef"
            }, {
              "path" : "declare namespace mext='http://midpoint.evolveum.com/xml/ns/public/model/extension-3'; extension/mext:objectclass"
            }, {
              "path" : "declare namespace mext='http://midpoint.evolveum.com/xml/ns/public/model/extension-3'; extension/mext:kind"
            } ]
          }, {
            "identifier" : "resourceOperationOptions",
            "display" : {
              "label" : "operationOptions"
            },
            "item" : [ {
              "path" : "declare namespace mext='http://midpoint.evolveum.com/xml/ns/public/model/extension-3'; extension/mext:dryRun"
            } ]
          } ]
        }
      }
    },
    "superArchetypeRef" : {
      "oid" : "00000000-0000-0000-0000-000000000511",
      "type" : "http://midpoint.evolveum.com/xml/ns/public/common/common-3#ArchetypeType"
    }
  }
}

The last archetype example is an extension of the resource related task. This archetype describes additional details for reconciliation tasks.

Reconciliation task (extends resource related task)
{
  "@ns" : "http://midpoint.evolveum.com/xml/ns/public/common/common-3",
  "archetype" : {
    "oid" : "00000000-0000-0000-0000-000000000541",
    "name" : "Reconciliation task",
    ....
    "archetypePolicy" : {
      "display" : {
        "label" : "Reconciliation task",
        "pluralLabel" : "Reconciliation tasks",
        "icon" : {
          "cssClass" : "fa fa-exchange"
        }
      },
      "itemConstraint" : [ {
        "path" : "declare namespace mext='http://midpoint.evolveum.com/xml/ns/public/model/extension-3'; extension/mext:objectQuery",
        "visibility" : "visible"
      }, {
        "path" : "declare namespace mext='http://midpoint.evolveum.com/xml/ns/public/model/extension-3'; extension/mext:finishOperationsOnly",
        "visibility" : "visible"
      } ],
      "adminGuiConfiguration" : {
        "objectDetails" : {
          "type" : "http://midpoint.evolveum.com/xml/ns/public/common/common-3#TaskType",
          "container" : [ {
            "identifier" : "resourceOptions",
            "display" : {
              "label" : "ReconciliationTask.resourceObjects"
            },
            "item" : {
              "path" : "declare namespace mext='http://midpoint.evolveum.com/xml/ns/public/model/extension-3'; extension/mext:objectQuery"
            }
          }, {
            "identifier" : "resourceOperationOptions",
            "display" : {
              "label" : "ReconciliationTask.reconciliationOptions"
            },
            "item" : {
              "path" : "declare namespace mext='http://midpoint.evolveum.com/xml/ns/public/model/extension-3'; extension/mext:finishOperationsOnly"
            }
          } ]
        }
      }
    },
    "superArchetypeRef" : {
      "oid" : "00000000-0000-0000-0000-000000000521",
      "type" : "http://midpoint.evolveum.com/xml/ns/public/common/common-3#ArchetypeType"
    }
  }
}

The examples above show a hierarchy for task archetypes: The basic task archetype is extended by the resource related task which is then extended by the reconciliation task archetype.

After assigning the reconciliation task archetype to a task, the merged archetype policy will then look as follows:

Reconciliation task archetype when merged
{
  "@ns" : "http://midpoint.evolveum.com/xml/ns/public/common/common-3",
  "archetype" : {
    "name" : "Basic task",
    "archetypePolicy" : {
      "display" : {
        "label" : "Reconciliation task",
        "pluralLabel" : "Reconciliation tasks",
        "icon" : {
          "cssClass" : "fa fa-exchange",
          "color" : "green"
        }
      },
      "itemConstraint" : [ {
        "path" : "declare namespace mext='http://midpoint.evolveum.com/xml/ns/public/model/extension-3'; extension/mext:objectQuery",
        "visibility" : "visible"
      }, {
        "path" : "declare namespace mext='http://midpoint.evolveum.com/xml/ns/public/model/extension-3'; extension/mext:finishOperationsOnly",
        "visibility" : "visible"
      }, {
        "path" : "extension",
        "visibility" : "vacant"
      }, {
        "path" : "declare namespace mext='http://midpoint.evolveum.com/xml/ns/public/model/extension-3'; extension/mext:objectclass",
        "visibility" : "visible"
      }, {
        "path" : "declare namespace mext='http://midpoint.evolveum.com/xml/ns/public/model/extension-3'; extension/mext:kind",
        "visibility" : "visible"
      }.... ],
      "adminGuiConfiguration" : {
        "objectDetails" : {
          "type" : "http://midpoint.evolveum.com/xml/ns/public/common/common-3#TaskType",
          "container" : [ {
            "identifier" : "resourceOptions",
            "display" : {
              "label" : "ReconciliationTask.resourceObjects"
            },
            "item" : [ {
              "path" : "declare namespace mext='http://midpoint.evolveum.com/xml/ns/public/model/extension-3'; extension/mext:objectQuery"
            }, {
              "path" : "objectRef"
            }, {
              "path" : "declare namespace mext='http://midpoint.evolveum.com/xml/ns/public/model/extension-3'; extension/mext:objectclass"
            }, {
              "path" : "declare namespace mext='http://midpoint.evolveum.com/xml/ns/public/model/extension-3'; extension/mext:kind"
            } ]
          }, {
            "identifier" : "resourceOperationOptions",
            "display" : {
              "label" : "ReconciliationTask.reconciliationOptions"
            },
            "item" : [ {
              "path" : "declare namespace mext='http://midpoint.evolveum.com/xml/ns/public/model/extension-3'; extension/mext:finishOperationsOnly"
            }, {
              "path" : "declare namespace mext='http://midpoint.evolveum.com/xml/ns/public/model/extension-3'; extension/mext:dryRun"
            } ]
          }, {
            "display" : {
              "label" : "Advanced options"
            },
            "displayOrder" : 150,
            "item" : [ {
              "path" : "cleanupAfterCompletion"
            }, {
              "path" : "threadStopAction"
            }, {
              "path" : "binding"
            }, {
              "path" : "dependent"
            } ]
          }, {
            "display" : {
              "label" : "Operational attributes (state)"
            },
            "displayOrder" : 900,
            "item" : [ {
              "path" : "executionStatus"
            }, {
              "path" : "node"
            }, {
              "path" : "nodeAsObserved"
            }, {
              "path" : "resultStatus"
            }... ]
          } ]
        }
      }
    },
    "superArchetypeRef" : {
      "oid" : "00000000-0000-0000-0000-000000000521",
      "type" : "http://midpoint.evolveum.com/xml/ns/public/common/common-3#ArchetypeType"
    }
  }
}

Limitations

The archetype functionality has the following limitations:

  • Archetype assignments must be direct and non-conditional.
    Indirect archetype assignments, such as inducements in roles, are not supported. Conditions, validity constraints, and any other assignment parameters and settings are not supported for archetype assignments.
    Archetypes form the backbone of the object type system. We will need to determine the exact types, schema, and policies applying to a particular object to correctly evaluate the conditions and any other complex mechanisms. Allowing conditional archetype assignments may lead to all kinds of chicken-and-egg problems. Therefore, we are explicitly disallowing indirect and conditional archetype assignments.

  • Archetypes cannot be applied to archetypes.
    In theory, archetypes may be applied to other archetypes, thus creating meta-archetypes. While some of that extra functionality may work, it has not been tested properly. Therefore, use this at your own risk.

  • An archetype can only be applied to one type.
    For example, you can apply an Employee archetype to users, and a Project archetype to orgs, however, you cannot apply one archetype to both users and orgs.

  • Archetypes are typically set once, ideally at the beginning of the lifecycle (object created from GUI with an archetype, archetype set by inbound mapping, etc.).
    Nevertheless, archetypes can be changed in a controlled way. Note that there may be some limitations. For example, a change of an archetype may require a change of the object schema which makes the change a sensitive operation.

  • Changing an archetype may lead to a dramatic change of policies (and also of the schema in future midPoint versions).
    Change of an archetype should not be taken lightly. The change may require manipulation of object data to proceed correctly. For example, you may need to remove items that are not allowed, or add items that are required by the new archetype.

  • Performance limitation.
    Do not create too many archetypes. They all need to be cached in RAM. Tens, or even hundreds or archetypes are perfectly fine. Thousands or more archetypes may cause issues.

  • assignmentRelation only works for archetypes.
    While theoretically, assignmentRelation can be placed in any assignment/inducement, this is not yet supported, as assignmentRelation has to be a first-order inducement (the inducement order must be 1). assignmentRelation is not supported in metaroles or other mechanisms that require higher-order inducements or inducement chaining.

  • Assignments/inducements that contain assignmentRelation must always be active (non-conditional, no activation).

  • assignmentRelation in archetype assignment is not fully supported yet.

  • assignmentRelation must be well specified.
    While the archetype definition may be missing, the object type and relation must always be specified. Full support for wildcard assignmentRelation is planned for later midPoint versions.

  • assignmentRelation only applies to limit the assignments between objects.
    It does not support limitations of inducements yet. I.e., there is no support for order constraints in the assignment relation specification. This feature is planned for later midPoint versions.

  • assignmentRelation does not limit the assignments that can be created (yet).
    The default behavior of assignments is open.

  • Archetype colors are not applied in the user interface consistently.
    E.g., the color of the "summary panel" on the user details page will be red, regardless of the archetype, as red is currently the color associated with users. This is planned to be improved later.

Refer to Archetype Improvements (Planned Feature) for future plans regarding archetype functionality development.

See also

Compliance

This feature is related to the following compliance frameworks:

Was this page helpful?
YES NO
Thanks for your feedback