[midPoint] Strange behavior during reconciliation

[Radovan Semancik]

Hi,

The situation is the same for adding values. E.g. the value may have 
been removed by an administrator. Or even the value that was given by 
user->account mapping of midPoint may have been explicitly deleted from 
the account in midPoint GUI. We cannot restore the value in 
reconciliation, because we are not sure which change was the last one. 
Again, strong mappings are the solution here.

I was not aware that recon will restore the associations if there is no 
association left. That looks like a bug. It should not restore the 
associations unless their mappings are set to strong.

-- 
Radovan Semancik
Software Architect
evolveum.com



On 02/24/2016 10:40 AM, Дорофеев Илья wrote:
>
> 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
>
>
>
> _______________________________________________
> 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/20160301/ec40d9f2/attachment.htm>