iterationin 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
iterationelement from object template and replace it with an integer value. Iteration specification element needs to be manually re-added as
iterationSpecificationafter 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.
primaryIdentifierValueproperty 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
primaryIdentifierValueproperty 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
primaryIdentifierValuemay 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.
assignmentTargetSearchexpressions were removed. Please use the
populatemechanisms 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.
accountcan no longer be used as top-level element for shadow objects. Element
shadowshould be used instead. MidPoint was using the correct
shadowelement 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
accountelement, 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
shadowsolves 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).
userTemplatecan no longer be used as top-level element for object template. Element
objectTempalteshould be used instead. This situation is almost the same as the
refis removed from resource synchronization section. Please use
handlerUrielement instead. The
refattribute 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
refattribute should be fixed before any attempts to upgrade to midPoint 4.0.