Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • Element iteration in object template was renamed to iterationSpecification. This change was needed due to major changes in midPoint object type hierarchy, somehow related to archetypes functionality. Object tempaltes need to be updated manually after the upgrade. The upgrade process will most likely remove the iteration element from object template and replace it with an integer value. Iteration specification element needs to be manually re-added as iterationSpecification after the upgrade. The trouble is that there is no warning about this happening. Attempt to add such warning were thwarted due to complex reasons related to schema processing and data parsing. This and the primaryIdentifierValue below are perhaps the only two really important issue to keep in mind when upgrading from midPoint 3.x to midPoint 4.0.
  • New primaryIdentifierValue property in shadows. MidPoint 3.x had chronic problems with shadow duplication. In  fact midPoint 3.x itself worked fine and bugs related to shadow duplication were quite rare and often limited to very exotic and parallel cases. However, it was very easy to make a configuration mistake that lead to shadow duplication. Duplicated shadows are a major issue in midPoint and they may lead to data inconsistencies that are difficult to resolve. Therefore midPoint 4.0 is introducing a mechanism that can limit shadow duplication on a database level. There is a new primaryIdentifierValue property that maps directly to a database column and there is an unique index on that. Therefore a whole class of possible shadow duplication problems is eliminated. The problem is that each resource object type may have different identifiers, normalization rules and so on. Therefore the computation of primaryIdentifierValue may be quite complex. This is beyond the possibilities of SQL migration scripts. Therefore midPoint 3.9 that was just upgraded to 4.0 will have null values for primaryIdentifierValue. Those values should be computed and stored by using shadow refresh task.
  • Elements relation and activation in assignmentTargetSearch expressions were removed. Please use the assignmentProperties and populate mechanisms instead. This would an ordinary deprecated and removal, however in this case there is one difference. The mechanism that detects deprecated and removed items will not detect this change. The cause of this is the fact, that expressions are not Prism containers, therefore midPoint schema-processing code does not have visibility inside those data structures.
  • Element account can no longer be used as top-level element for shadow objects. Element shadow should be used instead. MidPoint was using the correct shadow element for years and years. Therefore this should not be a significant problem during an upgrade unless there are some ancient manually-created shadows. MidPoint will indicate an error while parsing the removed 4.0.1 will parse even the data with account element, however, due to the similar reasons than above the error is not very clear. It will indicate class-cast problems. Changing the top-level element from account to shadow solves the problemautomatically converting them to shadow. The data in the database should be cleared up when the shadow objects are updated (e.g. during reconciliation).
  • Element userTemplate can no longer be used as top-level element for object template. Element objectTempalte should be used instead. This situation is almost the same as the account case above.
  • Attribute ref is removed from resource synchronization section. Please use handlerUri element instead. The ref attribute was deprecated even in midPoint 2.x. As this is an attribute and not an element then the automatic detector of removed elements does not work correctly in this case. The use of ref attribute should be fixed before any attempts to upgrade to midPoint 4.0.