Versions Compared


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


  • The legacy CSVFile Connector was replaced by new CSV Connector. The new CSV connector is a rewrite from scratch. The old CSVFile connector was written even before midPoint project started and it was not designed for real deployment use. We have maintained and improved the connector during the years. But it was not maintainable any more. Also the ConnId framework evolved over the time and we needed a connector that will use these features. Therefore we have decided to rewrite the connector completely. MidPoint 3.6 no longer bundles the old connector. New CSV connector is bundled instead. Old CSV connector can still be used and it is still supported for deployments that purchased midPoint subscription before midPoint 3.6 was released. As the old connector is not bundled with midPoint any more you have to download the connector JAR and deploy it explicitly. Full migration guide can be found here: Release 3.7 - PLANNED
  • The LDAP connector and AD Connector were upgraded to the latest available version. 

Behavior changes since 3.6 and 3.6.1

  • In approval-related expressions (e.g. stage auto-completion conditions), do not use midpoint.getChannel() to obtain the channel for the original request. It is not present when evaluating approval process preview (
    serverEvolveum Jira
    ). Use new channel variable instead.

Behavior changes since 3.5 and 3.5.1

  • Approval requests for which are no approvers defined (at a particular approval schema level) are now rejected by default. Original behavior was so that they were approved. Now the behavior is configurable using outcomeIfNoApprovers property of an approval schema level.
  • Work item notifications have changed. The workItemEvent category is abstract now; it was replaced with workItemLifecycleEvent, workItemAllocationEvent, workItemCompletionEvent, workItemDelegationEvent, workItemCustomEvent (TODO).
  • The focus object lifecycle state influences assignment lifecycle. If the object is inactive due to the lifecycle state then also the assignment will be considered inactive.
  • Deprecated password policy references in system configuration and orgs cannot be used together with security policy definitions. Please use password policy settings in the security policy.
  • Midpoint 3.5.1 and earlier assumed default value of 1 for minOccurs in the password policy. However, if no password policy was specified then the midOccurs defaulted to 0. This was unintuitive and inconsistent. The root cause of the problem was that the default value of midOccurs was never specified. Therefore the default value was consistently set to 0 in midPoint 3.6 and later.
    WARNING: this means that the password policy in midPoint 3.6 will allow entry of empty password unless minOccurs=1 is explicitly specified in the password policy.
  • Password history is stored in hashed form by default. The default storage form was encryption before midPoint 3.6. Old password history entries will remain in the form in which they were originally stored. New password history entries will be stored according to new setting.
  • Strong password mapping in previews midPoint versions worked in almost the same way as normal mapping. Strong password mapping in new midPoint version behaves in the same way as other strong mappings. However there is a crucial difference. The password is usually non-readable attribute. Therefore strong password mapping will overwrite password value every time the mapping is used. It is not recommended to use strong password mappings unless for very specific use-cases.
  • Some midPoint user interface URLs were changed in midPoint 3.6. Please review your bookmarks, mail templates and other configuration that may depend on specific user interface URLs.
  • MidPoint 3.5.x and earlier had not evaluated authorizations during search properly. The query was not taken into consideration when evaluating the authorization which may lead to information leak. That was fixed in midPoint 3.6 (MID-3916). This means that wrong or incomplete authorizations might work in until midPoint 3.6, but these will no longer work.
  • There is a change in processing relations in the assignments:
    • non-member (default) and non-delegation (deputy) relations are skipped on login time. Any authorizations in these assignments will be ignored.
    • approver and owner relations are skipped during recompute and all object operations. Any inducements in these relations will not be applied.
    This is temporary hard-coded behavior of the relations in midPoint. It was needed to enable usability and scalability of the system. The permanent solution is to enable configuration of individual relations and their behavior (
    serverEvolveum Jira
  • Policy Rules with multiple constrains are evaluated in such a way that logical AND operation is assumed between the constraints. Prior to midPoint 3.6 the exclusion policy constraints were mistakenly evaluated with logical OR. In midPoint 3.6 the evaluation of multiple exclusion constraints is not supported yet and attempt to evaluate such constraints will result in an error. The solution is to use several individual policy rules.
  • Previous midPoint versions applied changes in attribute and association mappings even in weaker assignment enforcement modes (none, positive). This was wrong and it was fixed in midPoint 3.6, but deployments that relied on the wrong behavior may be affected.