<div dir="ltr">Hi Tom,<div><br></div><div>as for the not-deleted-projection i believe you need to configure your projection policy and also check your schemaHandling/existence if changed.</div><div><br></div><div>see <a href="https://wiki.evolveum.com/display/midPoint/Projection+Policy">https://wiki.evolveum.com/display/midPoint/Projection+Policy</a></div><div><br></div><div>arnost</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">po 30. 9. 2019 v 17:52 odesílatel Tom Miller <<a href="mailto:tommillermp@gmail.com">tommillermp@gmail.com</a>> napsal:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi everyone!<br><br>Has anyone tried to modify an existing role yet?<br>It seems like changes in the role hierarchy are not distributed to the resources correctly after Recomputation.<br><br><br>1) The scenario starts like this:<br><ul><li>The user 'Testuser' has an assignment to the empty 'Root-Role'.</li></ul>2) In the second step, I edit the role 'Root-Role':<br><ul><li>The 'Resource-Role' has an account construction inducement for a resource (e.g. dummy CSV).</li><li>The 'Root-Role' has an inducement to the 'Resource-Role'.</li></ul>Because of MidPoint's eventual consistency, I start a Recomputation of all 'Root-Role' members.<br><br>A projection for the resource is created for the 'Testuser'. So far so good.<br><br>3) In the third step, I edit the role 'Root-Role' again:<br><ul><li>The inducement to 'Resource-Role' is removed from the 'Root-Role'.</li></ul>To regain consistency, I start a Recomputation of all 'Root-Role' members again.<br><br>Nothing happens.<br>The user 'Testuser' still has his projection for the resource (which should be deleted).<br>Only one thing happened: The <roleMembershipRef> to 'Resource-Role' was removed during Recomputation.<br><br><br>The same bahaviour happened as I tried these variations:<br><ul><li>Deactivating the inducement ('Root-Role' -> 'Resource-Role') instead of deleting it</li><li>Reconciling the user 'Testuser' instead of starting the Recomputation of all members of role 'Root-Role'</li><li>Use different <strength> values for the construction inducement in the 'Resource-Role'</li></ul><br>Sidenote: The system behaves in the same (wrong?) way, when I replace the construction inducement with a group projection.<br>In this case, the user should already have an account in the resource.<br><br>Interestingly, this operation still work:<br><ul><li>If I directly assign the 'Resource-Role' to the 'Testuser', the projection is created correctly.</li><li>If I remove the direct assignment of 'Resource-Role' from the 'Testuser', the projection is deleted correctly.</li></ul><br>Sidenote: The Enforcement Options of the resources are set to the default value ('relative' with no legalization).<br>This should create accounts after assignment and delete accounts after unassignment.<br>Other accounts in the resource should not be touched.<br>The other Enforcement Options and the Legalization are not useful in my scenario (I don't want all unassigned accounts to be whiped from the resource).<br><br><br>The problem seems to be, that the Reconcile/Recompute job doesn't know, that there had ever been an indirect assignment to the 'Resource-Role'.<br>Instead, the job behaves like the projetion was created manually for the user.<br>Because of this, there seems to be nothing to recompute for MidPoint.<br><br><br>I tried to analyze this behavior in a primary hook and found something interesting:<br>When a role is assigned/unassigned directly to a user, this is visible in the <assignment> section and there is a delta with this change.<br>When a role is assigned/unassigned indirectly to a user, this is visible in the <font face="monospace"><roleMembershipRef></font> section, but there is no delta at all.<br>I assume, this causes the different treatment of direct and indirect assignments.<br><br>If indirect assignments (<font face="monospace"><roleMembershipRef></font>) would be treated like direct assignments (<font face="monospace"><assignment></font>), then everything would propably work as expected.<br>Changes made to the role hierarchy would cause an effect during Reconcile/Recompute, because the <roleMembershipRef> are already added and removed correctly right now.<br><br><br>Is there any recommended way, how to make changes to the role hierarchy?<br><br>Are there any configurations with which MidPoint can process indirect assignments EXACTLY like direct assignments?<br><br>Is there any setting or configuration with which MidPoint can process the changes made to indirect assignments when recomputing?<br><br>Can I trigger the reconcilation of a role member with some kind of delta (e.g. 'remove indirect assignment')?<br><br><br>The configuration for my problem looks like this:<br><br><font face="monospace"><role oid="11111111-9ac3-4c09-8bb1-c151bd8cd128"><br>    <name>Resource-Role</name><br></font><font face="monospace">    <inducement></font><div><font face="monospace">        <construction><br>            <strength>strong</strength><br>            <resourceRef oid="33333333-9d55-4bf6-8fd3-d9c7a6f0bd03" relation="org:default" type="c:ResourceType"><br>                <!-- CSV-System --><br>            </resourceRef><br>            <kind>account</kind><br>            <intent>default</intent><br>        </construction><br>    </inducement><br></role><br><br><role oid="22222222-afa2-4a2e-9d3e-c7e8738c673d"><br>    <name>Root-Role</name><br>    <inducement><br>        <targetRef oid="11111111-9ac3-4c09-8bb1-c151bd8cd128" relation="org:default" type="c:RoleType"><br>            <!-- Resource-Role --><br>        </targetRef><br>    </inducement><br></role><br><br><user oid="00000000-d56b-4c7d-baf7-61c98afa8851"><br>    <name>Testuser</name><br>    <assignment><br>        <targetRef oid="22222222-afa2-4a2e-9d3e-c7e8738c673d" relation="org:default" type="c:RoleType"><br>            <!-- Root-Role --><br>        </targetRef><br>    </assignment><br></user></font><br><br><br>I hope anyone can help me...<br>Thanks in advance!<br></div></div>
_______________________________________________<br>
midPoint mailing list<br>
<a href="mailto:midPoint@lists.evolveum.com" target="_blank">midPoint@lists.evolveum.com</a><br>
<a href="http://lists.evolveum.com/mailman/listinfo/midpoint" rel="noreferrer" target="_blank">http://lists.evolveum.com/mailman/listinfo/midpoint</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:13px"><p><strong>Arnošt Starosta</strong><br><span style="font-size:11px;color:rgb(128,128,128)">solution architect</span></p></div><p style="color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:11px">gsm: [+420] 603 794 932<br>e‑mail: <a href="mailto:arnost.starosta@ami.cz" target="_blank">arnost.starosta@ami.cz</a></p><p style="color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:11px"><strong>AMI Praha a.s.</strong><br>Pláničkova 11, 162 00 Praha 6</p><p style="color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:11px">tel.: [+420] 274 783 239 | web: <a href="https://www.ami.cz" target="_blank">www.ami.cz</a></p><p style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif;font-size:10px;margin-top:20px"><img src="http://www.ami.cz/images/podpis/ami_logo.gif" alt="AMI Praha a.s." style="border: 0px;"></p><p style="font-family:Arial,sans-serif;font-size:11px;color:rgb(170,170,170)">Textem tohoto e‑mailu podepisující neslibuje uzavřít ani neuzavírá za společnost AMI Praha a.s.<br>jakoukoliv smlouvu. Každá smlouva, pokud bude uzavřena, musí mít výhradně písemnou formu.<br><span style="font-size:6px"> </span><br>Tento e‑mail je určen výhradně pro potřeby jeho adresáta/ů a může obsahovat důvěrné nebo osobní<br>informace. Nejste‑li zamýšleným příjemcem, je zakázáno jakékoliv zveřejňování, zprostředkování<br>nebo jiné použití těchto informací. Pokud jste obdrželi e‑mail neoprávněně, informujte o tom prosím<br>odesílatele a vymažte neprodleně všechny kopie tohoto e‑mailu včetně všech jeho příloh. Nakládáním<br>s neoprávněně získanými informacemi se vystavujete riziku právního postihu.</p></div></div></div></div>