[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