[midPoint] Strange behavior during reconciliation

[Дорофеев Илья]

Hi Radovan,

Thanks for clarification of the purpose of normal-strength mappings. But my question was about adding values during reconciliation and not overwriting and deleting them. Consider the case mentioned in my initial message: an account should have three associations A, B and C computed by some normal mappings (say, in account construction assignment). But actually the account has only association A (suppose others were removed directly on the resource). In this case reconciliation won’t restore the missing associations. Ok, let’s say that we don’t want to overwrite the decisions made by a resource administrator. But if you manually remove the last association A so the account won’t have any associations at all, then reconciliation will restore all three associations. In my view, this behavior seems to be a bit inconsistent. What do you think?
__________________________

Ilya Dorofeev

From: midPoint [mailto:midpoint-bounces at lists.evolveum.com] On Behalf Of Radovan Semancik
Sent: Monday, February 22, 2016 12:18 PM
To: midpoint at lists.evolveum.com
Subject: Re: [midPoint] Strange behavior during reconciliation

Hi Ilya,

Yes, this is done by purpose. I have realized that this might not be entirely clear, so I have just added this info to the documentation:

"Please note that the only mappings that will reliably overwrite a value during reconciliation are strong mappings. Weak and normal mappings will not overwrite or delete a value. This may be a slightly surprising behavior of normal mappings, but this is done by purpose. Normal mappings are based on processing relative changes. But during reconciliation there is no change in the source data. Therefore there is also no reason to apply normal mappings.
Normal-strength mappings are the default setting in midPoint. As usual, midPoint has conservative default settings that try to avoid destroying the values on target systems. This is a good setting when midPoint is deployed, new systems are connected or when midPoint operates in semi-authoritative mode. But once the midPoint is fully authoritative and the policies are properly defined and tested the mappings are usually switched to strong setting."

(https://wiki.evolveum.com/display/midPoint/Mapping)



--

Radovan Semancik

Software Architect

evolveum.com


On 02/19/2016 03:22 PM, Дорофеев Илья wrote:
Hi guys,

I’m currently exploring how the reconciliation works. The one interesting thing I’ve ran into is the code below found in ReconciliationProcessor.reconcileProjectionAssociations method (lines 490-497):
if (shouldBeMapping.getStrength() != MappingStrengthType.STRONG && (!areCValues.isEmpty() || hasStrongShouldBeCValue)) {
   // weak or normal value and the attribute already has a
   // value. Skip it.
   // we cannot override it as it might have been legally
   // changed directly on the projection resource object
   continue;
}

This code postulates that I cannot provision values (which are associations here in fact) produced by mappings of normal strength (which is default) if a resource object already has a non-empty list of associations. It means that if some midpoint policy of normal strength requires an account to have the associations with the entitlements A, B and C, and this account is actually associated only with A (say, B and C are removed from the account directly on the resource), then the reconciliation won’t restore missing associations with B and C. Is this the intentional behavior or is it a bug? In my view, this code only makes sense for single-valued attributes when we don’t want to override the values set outside the IdM. In case of multi-valued attribute, no overriding is actually happens because we only add values but do not replace them.

__________________________

Ilya Dorofeev




_______________________________________________

midPoint mailing list

midPoint at lists.evolveum.com<mailto:midPoint at lists.evolveum.com>

http://lists.evolveum.com/mailman/listinfo/midpoint

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20160224/53f1f467/attachment.htm>