<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"Segoe UI";
        panose-1:2 11 5 2 4 2 4 2 2 3;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:black;
        mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"Стандартный HTML Знак";
        margin:0cm;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";
        color:black;}
span.HTML
        {mso-style-name:"Стандартный HTML Знак";
        mso-style-priority:99;
        mso-style-link:"Стандартный HTML";
        font-family:Consolas;
        color:black;}
span.EmailStyle19
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle20
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:2.0cm 42.5pt 2.0cm 3.0cm;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="RU" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Hi Radovan,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">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?<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt;font-family:"Segoe UI",sans-serif;color:#1F497D;mso-fareast-language:RU">__________________________<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt;font-family:"Segoe UI",sans-serif;color:#1F497D;mso-fareast-language:RU"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt;font-family:"Segoe UI",sans-serif;color:#1F497D;mso-fareast-language:RU">Ilya Dorofeev<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="color:windowtext;mso-fareast-language:RU">From:</span></b><span style="color:windowtext;mso-fareast-language:RU"> midPoint [mailto:midpoint-bounces@lists.evolveum.com]
<b>On Behalf Of </b>Radovan Semancik<br>
<b>Sent:</b> Monday, February 22, 2016 12:18 PM<br>
<b>To:</b> midpoint@lists.evolveum.com<br>
<b>Subject:</b> Re: [midPoint] Strange behavior during reconciliation<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Hi Ilya,<br>
<br>
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:<br>
<br>
"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.<br>
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."<br>
<br>
(<a href="https://wiki.evolveum.com/display/midPoint/Mapping">https://wiki.evolveum.com/display/midPoint/Mapping</a>)<br>
<br>
<br>
<span style="font-size:12.0pt;mso-fareast-language:RU"><o:p></o:p></span></p>
<pre>-- <o:p></o:p></pre>
<pre>Radovan Semancik<o:p></o:p></pre>
<pre>Software Architect<o:p></o:p></pre>
<pre>evolveum.com<o:p></o:p></pre>
<p class="MsoNormal"><br>
<br>
On 02/19/2016 03:22 PM, Дорофеев Илья wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span lang="EN-US">Hi guys,</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">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):</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">if (shouldBeMapping.getStrength() != MappingStrengthType.STRONG && (!areCValues.isEmpty() || hasStrongShouldBeCValue)) {</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">   // weak or normal value and the attribute already has a</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">   // value. Skip it.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">   // we cannot override it as it might have been legally</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">   // changed directly on the projection resource object</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">   continue;</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">}</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US">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.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt">__________________________</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt">Ilya Dorofeev</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;mso-fareast-language:RU"><br>
<br>
<br>
<o:p></o:p></span></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>midPoint mailing list<o:p></o:p></pre>
<pre><a href="mailto:midPoint@lists.evolveum.com">midPoint@lists.evolveum.com</a><o:p></o:p></pre>
<pre><a href="http://lists.evolveum.com/mailman/listinfo/midpoint">http://lists.evolveum.com/mailman/listinfo/midpoint</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;mso-fareast-language:RU"><o:p> </o:p></span></p>
</div>
</body>
</html>