- Only User, Role, Org and Service archetypes are supported in 4.0. Archetypes are designed to work with many object types, including tasks and resources. And in theory, archetypes may be applied to archetypes themselves, creating meta-archetypes. But all of that is not fully supported yet. Some of that extra functionality may work, but it is not tested properly. Therefore use it at your own risk only.
- Performance limitation: Do not create too many archetypes. They all need to be cached in RAM. Tens or even hundreds are perfectly fine. Thousands or more may be a problem.
- AssignmentRelation works only in archetypes. While theoretically assignmentRelation can be placed in any assignment/inducement, this is not yet supported. It must be a first-order inducement (inducement order must be 1). Assignment relation in metaroles or other mechanism that requires higher-order inducement or inducement chaining are not supported yet.
- assignment/inducement that contains assignmentRelation must be always active (non-conditional, no activation)
- AssignmentRelation in archetype assignment is not fully supported yet.
- AssignmentRelation must be (almost) fully specified to work well in midPoint 4.0. Only the archetype definition may be missing. Object type and relation must always be specified. Full support for wildcard assignmentRelations 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. That is planned for later midPoint versions.
- AssignmentRelation does not limit the assignments that can be created - yet. The default behaviour of assignments is open (see above). Assignment relation is used in midPoint 4.0 mostly to render special button for user convenience.
- Archetype assignments are not supposed to change during the lifetime of an object. Archetypes should be set once, ideally at the beginning of lifecycle (object created from GUI with an archetype, archetype set by inbound mapping, etc.). The archetype should be fixed and it should never change. That is expected behavior for midPoint 4.0. This behavior can can change in later midPoint versions. However, there still will be some limitations about archetype change. Change of archetype may mean change of object schema, therefore this will always be a sensitive operation.
- There is no user interface to conveniently manage archetype definitions yet.
- Archetypes of archetypes (meta-archetypes) are not supported yet.
- Archetype colors are not applied in the user interface consistently. E.g. the color of "summary panel" on user details page will be red, regardless of the archetype, as red is currently color associated with users. This is planned to be improved later.
- User type colors from 3.x are currently hardcoded in the system. Therefore users are displayed in the menu as red. The plan is to be able to configure this behavior in the future.