<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Aivo,</p>
<p><br>
</p>
<p>having looked at the documentation and the code, I think that:</p>
<ol>
<li>it is possible (in 3.4) to allow user "request" removing
existing assignments - to be executed immediately, without any
approvals - simply by creating an authorization for action of
(...)authorization-model-3#unassign.</li>
<li>If you'd like to have such unassignments approved by role
approver, it could be implemented by cloning and updating
AddAssignmentAspect (and its subclasses). It should not be too
much work, if needed.</li>
</ol>
<p>Best regards,<br>
</p>
<pre class="moz-signature" cols="72">Pavol Mederly
Software developer
evolveum.com
</pre>
<div class="moz-cite-prefix">On 12.08.2016 12:11, Aivo Kuhlberg
wrote:<br>
</div>
<blockquote cite="mid:1470996677556.98062@rmit.ee" 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>
<p>Hi Pavol,</p>
<p>Thanks for the answers.<br>
</p>
<blockquote>
<p><em>This is an interesting question. Do you want this
operation to be carried out automatically (without
approval), or to be approved in the same way as assignment
creation?</em><br>
</p>
</blockquote>
<p>I was thinking about creating request for removing user's
current assignment. It is just theoretical question at the
moment and I don't think this feature might be much needed in
real life - maybe only when user notices that he/she has
assigned to wrong role (may happen when there are many roles)
and then user sends request to "unassign" the wrong role and
assign correct one.<br>
</p>
<p><br>
</p>
<p>Regards,</p>
<p>Aivo<br>
</p>
<div style="color: rgb(33, 33, 33);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>Saatja:</b>
midPoint <a class="moz-txt-link-rfc2396E" href="mailto:midpoint-bounces@lists.evolveum.com"><midpoint-bounces@lists.evolveum.com></a>
nimelPavol Mederly <a class="moz-txt-link-rfc2396E" href="mailto:mederly@evolveum.com"><mederly@evolveum.com></a><br>
<b>Saadetud:</b> 12. august 2016 12:12<br>
<b>Adressaat:</b> <a class="moz-txt-link-abbreviated" href="mailto:midpoint@lists.evolveum.com">midpoint@lists.evolveum.com</a><br>
<b>Teema:</b> Re: [midPoint] Role request questions</font>
<div> </div>
</div>
<div>
<p>Hello Aivo,</p>
<p><br>
</p>
<p>please see answers in your text.</p>
<p><br>
</p>
<p>Best regards,<br>
</p>
<pre class="moz-signature" cols="72">Pavol Mederly
Software developer
evolveum.com
</pre>
<blockquote type="cite">When I request a role (which have
approver) then I don't see the request under My Requests.
Does the requester needs some authorization to view his/her
currently active requests?</blockquote>
<br>
Yes. <br>
<br>
The background is this: Information about an approval process
is stored in midPoint task (as well as in Activiti process
instance, but that's not important now). In 3.4, we are not
able to specify authorization for tasks to allow displaying
only the tasks that are somehow related to the user. We are
limited to quite static conditions, like "show tasks that
belong to a (fixed) user", or "show tasks that were requested
by a (fixed) user". So, basically, you'd need a separate role
for each possible requester, and that's obviously a nonsense.<br>
<br>
This more flexible mechanism is to be implemented in 3.5, as
per <a moz-do-not-send="true"
href="https://jira.evolveum.com/browse/MID-3121">
https://jira.evolveum.com/browse/MID-3121</a>. (It's little
bit unclear if it will really fit into the schedule, but
that's another story.)<br>
<br>
As a workaround for 3.4, you could give users read access to
workflowContext section of
<i>all</i> tasks. If you disallow non-GUI access for them, and
disallow using Task List page, it could be reasonably secure.
(Based on the fact that the users will not know tasks' OIDs to
access them directly.) But it depends on how secure you want
your system to be.<br>
<br>
<blockquote type="cite">Can user request to remove the
assigned roles? By default it does not seem to work?<br>
</blockquote>
<br>
This is an interesting question. Do you want this operation to
be carried out automatically (without approval), or to be
approved in the same way as assignment creation?<br>
<br>
<blockquote type="cite">Is it possible in request roles dialog
to hide from available roles the roles which have already
assigned to user and/or roles which user has already
requested but have not yet approved?<br>
</blockquote>
<br>
Currently it is (as far as I know) not implemented. I think it
is not a too much work to be done. (Please create a jira if
you're interested.)<br>
<br>
There is one aspect that comes to mind: An assignment can be
e.g. disabled, or valid only through a period of time, or be
bound to a specific org or tenant, or have any parameters that
make it different from other assignments of the given role. So
there might be reason to add a role for which some assignment
already exists. Therefore, this feature should be configurable
(by administrator, knowing the deployment details), or should
be switchable on/off by the user.<br>
<br>
<blockquote type="cite">By default when role is requestable
but have no approver the end user can order a role without
any approval - is it possible to avoid such situation, eg by
defining some kind of policy that when request have no any
approving users then the administrator still has to approve
it?</blockquote>
<br>
Good idea! I am convinced this can be done using
authorizations mechanism: To allow end user see only roles
that have non-empty approverRef field.<br>
<br>
</div>
</div>
<br>
<hr>
<font face="Arial" color="Gray" size="2">Käesolev e-kiri võib
sisaldada asutusesiseseks kasutamiseks tunnistatud teavet.<br>
This e-mail may contain information which is classified for
official use.</font>
<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>
</body>
</html>