[midPoint] Strange behavior during reconciliation

[Radovan Semancik]

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
> http://lists.evolveum.com/mailman/listinfo/midpoint


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20160222/4076fceb/attachment.htm>