[midPoint-git] [Evolveum/midpoint] 6c8ddc: Fix fetching incompatible associations

mederly noreply at github.com
Mon Apr 29 19:09:26 CEST 2024


  Branch: refs/heads/support-4.8
  Home:   https://github.com/Evolveum/midpoint
  Commit: 6c8ddc2fd1d44d44b6ef0bd49a2c29ece4b57742
      https://github.com/Evolveum/midpoint/commit/6c8ddc2fd1d44d44b6ef0bd49a2c29ece4b57742
  Author: Pavol Mederly <mederly at evolveum.com>
  Date:   2024-04-29 (Mon, 29 Apr 2024)

  Changed paths:
    M model/model-intest/src/test/java/com/evolveum/midpoint/model/intest/TestIntent.java
    A model/model-intest/src/test/resources/intents/resource-dummy-intents.xml
    M provisioning/provisioning-impl/src/main/java/com/evolveum/midpoint/provisioning/impl/shadows/ShadowedObjectConstruction.java

  Log Message:
  -----------
  Fix fetching incompatible associations

When having two account types, the first with an association defined
(account/IA), and second one without one (account/IB); and only ex-post
("after retrieval") classification using <classificationCondition>,
then searching for account/IA fails on a shadow S of type account/IB,
if it has a value for that association.

The reason is that the search for associations on S is based on
the definition of IA (so the association value is found), then comes
the classification that determines the type to be IB, and then
the association value becomes illegal.

This commit fixes that by removing such illegal association values.

This resolves MID-9591. However, the recommended way is to avoid
<classificationCondition> and to use delineation <filter> instead.
That way, all accounts found will be compatible with the follow-on
processing.



To unsubscribe from these emails, change your notification settings at https://github.com/Evolveum/midpoint/settings/notifications


More information about the midPoint-svn mailing list