<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi,<br>
<br>
I would like to clarify: There is usually not much sense in
approving or rejecting a change that was detected by livesync in
the way that approval process usually works. The change detected
by livesync have already happened. So there is no option to
"reject" it. That's the main reason it is not implemented.<br>
<br>
Similar matter are the changes to focus (e.g. User) objects that
are mapped from the livesync using the inbound mappings. Current
midPoint philosophy considers mappings to be always authoritative.
So again, there is no point in approving any changes that have
originated from the mappings. It is not easy to "reject" such
changes. Well, in livesync it might by a possibility, as the sync
event that caused them is not likely to be processed again. But
when it comes to reconciliation there is a problem: if you reject
a change originated from a mapping then the same change will
re-appear on another reconciliation run and you will have to
reject it again. And no as no livesync is ever 100% reliable then
a good midPoint deployment always has a secondary synchronization
mechanism to pick up changes that livesync missed. This is usually
reconciliation. So in the end even the livesync method is likely
to fail because the next recon run will ruin all the previous
decisions.<br>
<br>
The approval process was designed for a use-case where midPoint is
the primary "manager" of what is legal and what is not. This is
the principle that all IDM systems that I know follow. While
midPoint goes into (really) great lengths to be flexible how
reality is aligned with the policy, there still needs to be one
place that authoritatively decides about the data that are input
to the policy. That does not necessarily needs to be midPoint.
MidPoint can take that information from another source (or several
sources). There just needs to be an algorithm how to determine the
policy data. The approval process is currently only viable for the
system which is the authoritative source of the policy data.<br>
<br>
But, I'm still quite curious about your use case. Can you perhaps
describe what are you trying to achieve? I mean from a user point
of view. Why exactly do you want to approve changes coming from a
lifesync? What is the motivation?<br>
<br>
<pre class="moz-signature" cols="72">--
Radovan Semancik
Software Architect
evolveum.com</pre>
<br>
<br>
On 05/05/2016 10:55 PM, Pavol Mederly wrote:<br>
</div>
<blockquote
cite="mid:c626a98f-4b27-5140-6010-0f445226e3a8@evolveum.com"
type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<p>Hello Ramiji,</p>
<p><br>
</p>
<p>the feature you're trying to use, i.e. approving changes that
were detected by LiveSync, has not been implemented yet.</p>
<p><br>
</p>
<p>We first implemented the most common scenario: approving
explicitly requested changes (submitted via GUI, Java, SOAP or
REST API).</p>
<p><br>
</p>
<p>What you need is probably not that hard to implement. What
needs to be clarified is exact expected behavior - for example,
should we consider changes detected only by LiveSync, or by
reconciliation as well?</p>
<p> a) If by LiveSync only: what with changes that would get
lost (somehow - it might happen for reasons internal or external
to midPoint). Normally, such changes are covered by
reconciliation. If we would forbid reconciliation, we would have
to have another mechanism for recovering such forgotten/lost
changes.<br>
</p>
<p> b) If by reconciliation as well: what with changes that
would be rejected? They would trigger new approval process at
each reconciliation task run.<br>
</p>
<p><br>
</p>
<p>Best regards,</p>
<p>Pavol<br>
</p>
<br>
<div class="moz-cite-prefix">On 05.05.2016 15:07, Rijndaal Ramiji
wrote:<br>
</div>
<blockquote
cite="mid:VI1PR06MB13126C93363DAFC4C6062F1DB77C0@VI1PR06MB1312.eurprd06.prod.outlook.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper"
style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>Hi.<br>
<br>
I'm currently studying workflows, and my admin project would
like to use it in the LiveSync provisioning process.<br>
<br>
We currently have an HR resource that has a livesync task.<br>
An object template for the sync event of HR can create the
CN for AD and stores it in $user/extension/CN.<br>
<br>
Finally, My ActiveDirectory resource has on outbound
mapping of $user/extension/CN in icfs:name.<br>
<br>
It works like a charm! (this product is quite of amazing
;) )</p>
<p><br>
</p>
<p>Btw, I'm reading about workflows of approval and we would
like to make the liveSync process of provisioning to be
overlooked by a workflow.<br>
<br>
I have configured the workflow process, and it works for,
example, creation of an user from MidPoint "new user".<br>
<br>
Before the effective provisioning on AD, it ask to the admin
to reject or approve the request of creation.<br>
<br>
This workflow sadly, seems to not work with the automatic
creation of the account from the "unmatched" reaction...<br>
<br>
Is this a known bug , <span style="font-family: Calibri,
Arial, Helvetica, sans-serif, 'Apple Color Emoji', 'Segoe
UI Emoji', NotoColorEmoji, 'Segoe UI Symbol', 'Android
Emoji', EmojiSymbols; font-size: 16px;">should </span>this be
the exact flow or maybe I have made something wrong?<br>
<span style="font-size: 12pt;"><br>
Thank you all! </span></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
midPoint mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:midPoint@lists.evolveum.com">midPoint@lists.evolveum.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.evolveum.com/mailman/listinfo/midpoint">http://lists.evolveum.com/mailman/listinfo/midpoint</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
midPoint mailing list
<a class="moz-txt-link-abbreviated" href="mailto:midPoint@lists.evolveum.com">midPoint@lists.evolveum.com</a>
<a class="moz-txt-link-freetext" href="http://lists.evolveum.com/mailman/listinfo/midpoint">http://lists.evolveum.com/mailman/listinfo/midpoint</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>