[midPoint] - Manual tasks notifications
Pavol Mederly
mederly at evolveum.com
Tue Aug 23 07:55:54 CEST 2016
Hello Rodrigo,
precisely speaking, resources do not listen to events. They just contain
a logic that midPoint uses to manage objects on "remote systems". Logic
is in the form of mappings: outbound mappings are used to store data on
these remote systems (i.e. to control the outbound flow of data: from
midPoint to remote resource), while inbound mappings are used to gather
data from these remote systems (i.e. to control the inbound flow of
data: from remote resource to midPoint). Mappings are described here:
https://wiki.evolveum.com/display/midPoint/Mapping.
Mappings often contain custom code, typically in groovy. And yes, it can
be used to trigger a workflow when invoked. But mappings are executed at
various moments. For example, not only when a role that induces resource
assignment is assigned to the user (this is the moment you are
interested in). But also when user account is changed. Or during
recomputation or reconciliation. It could be hacked somehow to
distinguish between these cases, but it is definitely not easy and
requires quite a deep knowledge of midPoint; plus a lot of
experimentation ;)
The more cleaner way how to include custom logic to midPoint processing
is using scripting hooks
<https://wiki.evolveum.com/display/midPoint/Scripting+Hooks>. Such a
hook could try to detect that a role X1, X2, ... or Xn was added to a
user and could trigger a workflow operation by adding (another) role
with an approver assigned to the user. But I have not tried something
like that yet.
The absolutely most clean way how to deal with your problem would be to
talk to Igor or Radovan about conditions that would allow us to
implement the missing functionality (MID-2457
<https://jira.evolveum.com/browse/MID-2457>), or at least parts of it
that you'd require.
Pavol Mederly
Software developer
evolveum.com
On 22.08.2016 15:10, Rodrigo Yanis wrote:
> Pavol, good day!
>
> I'm sorry if I wasn't clear enough. To answer your questions; yes,
> that would be a standard midPoint resource object indeed. From my
> understanding (please correct me if I'm wrong), midPoint resources
> would be able to listen events related to entitlements - and those
> entitlements, would be linked to roles. As such, that would allow us
> to trigger custom logic upon different entitlement-related events. My
> primary concern is - would that standard midPoint resource be able to
> trigger a workflow on an entitlement-related event? If that's the
> case, then we might be able to tackle the cases I've described before.
>
> Let me know if this makes any sense to you.
>
> Thanks for your help.
> Regards,
>
>
> *Rodrigo Yanis.*
> Identicum S.A.
> Jorge Newbery 3226
> Tel: +54 (11) 4824-9971
> ryanis at identicum.com <mailto:ryanis at identicum.com>
> www.identicum.com <http://www.identicum.com/>
>
> 2016-08-22 4:14 GMT-03:00 Pavol Mederly <mederly at evolveum.com
> <mailto:mederly at evolveum.com>>:
>
> Hello Rodrigo,
>
> I'm afraid that I don't quite understand your alternatives. For
> example, what do you mean by "resource" in "a" and "b"? Is it a
> standard midPoint resource object? How it could listen to events
> related to user roles? Do you mean that it should have mappings
> that would invoke Java code that would start corresponding
> approval workflows? (Probably not.)
>
> Similarly, I don't understand what you mean by "exteriorizing"
> Position data structure.
>
> Please, could you describe your ideas in more details? We'd be
> glad to help you.
>
> Pavol Mederly
> Software developer
> evolveum.com <http://evolveum.com>
>
> On 19.08.2016 23:22, Rodrigo Yanis wrote:
>> Pavol,
>>
>> Thanks for your insight - yes, the case that you describe is one
>> of the cases that we're facing here, but not the only one. The
>> other scenario that we would like to represent is described by
>> the following flow:
>>
>> 1. A user is provisioned by a set or roles X1,X2,X3,...,Xn that
>> are inherited as he gets a value in an attribute that has those
>> roles linked (calling that attribute, eg. Position)
>> 2. Role Xn approver (that is, the owner of an external resource
>> Xn) gets an approval activity for that role to be provisioned in
>> MP as well as a notification indicating that this should be
>> manually applied into resource Xn.
>> 3. Role Xn approver, approves such request, provisioning the user
>> with role Xn, as he also perform this task on his respective domain.
>>
>> I understand the difficulty here comes in (1) as we cannot
>> trigger an approval workflow per each linked role to that
>> particular Position.
>>
>> So we came up with these alternatives - please let me know what's
>> your perspective on them;
>> By priority and "cleanliness" order,
>> a. To implement a MP resource which would perform on the Java API
>> level, prior having linked roles to entitlements, having this
>> resource to listen the events related to these entitlements and
>> then execute an approval workflow for granting that entitlement
>> to that user.
>> b. Same as (a), but instead, it would be a resource working on
>> the MP REST level.
>> c. (Ugly) To exteriorize the Position data structure (all linked
>> roles, with their respective owners) + delegate the manual task
>> notifications and calls to initialize a workflow in MP to an
>> external database, having a MP DB resource listening to
>> entitlement changes for event handling.
>>
>> Let me know if there's something I'm not being clear about.
>>
>> Very grateful for your assistance.
>>
>> Thanks.
>>
>>
>> *Rodrigo Yanis.*
>> Identicum S.A.
>> Jorge Newbery 3226
>> Tel: +54 (11) 4824-9971
>> ryanis at identicum.com <mailto:ryanis at identicum.com>
>> www.identicum.com <http://www.identicum.com/>
>>
>> 2016-08-19 16:11 GMT-03:00 Pavol Mederly
>> <pavol.mederly at evolveum.com <mailto:pavol.mederly at evolveum.com>>:
>>
>> Rodrigo,
>>
>> use of workflows in midPoint is currently limited to
>> approving requested changes. So, today there's no way of
>> starting a workflow that would present a user a work item
>> like "hey you, please do this and then click 'Done'". We plan
>> to implement a "manual provisioning" but it requires a
>> nontrivial amount of effort, see
>> https://jira.evolveum.com/browse/MID-2457
>> <https://jira.evolveum.com/browse/MID-2457>.
>>
>> But maybe there's a hack possible. Workflows can be used to
>> approve a change. For example, midPoint is able to approve a
>> role assignment addition (out of the box). Or an attribute
>> change (with some custom coding).
>>
>> If I understand your situation correctly, maybe you could do
>> it like this:
>>
>> 1. You have a resource X that requires manual intervention
>> by an administrator in order to assign role X1 to an
>> account on this resource.
>> 2. So, you can create a midPoint role RoleX1, with approver
>> defined to be the resource administrator.
>> 3. If someone assigns RoleX1 to a midPoint user, an approval
>> workflow process is started, notifying the resource
>> administrator that he has to "approve" assignment of
>> RoleX1 to midPoint user.
>> 4. At this point, he knows he has to manually assign role X1
>> on X to user's account.
>> 5. So he does it, and marks the assignment as "Approved".
>> 6. The assignment of RoleX1 is then added to the user, so he
>> knows that everything is done (in particular that the
>> role X1 on resource X was added to him).
>>
>> Does this make sense to you?
>>
>> Best regards,
>> Pavol
>>
>>
>>
>> ------------------------------------------------------------------------
>> *From: *"Rodrigo Yanis" <ryanis at identicum.com
>> <mailto:ryanis at identicum.com>>
>> *To: *"midPoint General Discussion"
>> <midpoint at lists.evolveum.com
>> <mailto:midpoint at lists.evolveum.com>>
>> *Sent: *Friday, August 19, 2016 8:48:20 PM
>> *Subject: *Re: [midPoint] - Manual tasks notifications
>>
>>
>> Bringing this up again - Do you know of a way for Midpoint
>> to, aside from sending that notification upon an attribute
>> change, to also trigger an internal Workflow that would allow
>> us to keep track of the manual workload? In this scenario,
>> the user gets the notification for the manual task, on
>> parallel, a workflow is triggered to trace the start of a
>> manual task, and would be manually updated by the user
>> throughout the change process.
>>
>> Is this "Workflow" idea somewhat plausible?
>>
>> Thanks a lot.
>>
>>
>> *Rodrigo Yanis.*
>> Identicum S.A.
>> Jorge Newbery 3226
>> Tel: +54 (11) 4824-9971
>> ryanis at identicum.com <mailto:ryanis at identicum.com>
>> www.identicum.com <http://www.identicum.com/>
>>
>> 2016-08-19 15:32 GMT-03:00 Rodrigo Yanis
>> <ryanis at identicum.com <mailto:ryanis at identicum.com>>:
>>
>> Excellent. We'll surely try this out.
>>
>> Thanks guys.
>>
>>
>> *Rodrigo Yanis.*
>> Identicum S.A.
>> Jorge Newbery 3226
>> Tel: +54 (11) 4824-9971
>> ryanis at identicum.com <mailto:ryanis at identicum.com>
>> www.identicum.com <http://www.identicum.com/>
>>
>> 2016-08-19 15:29 GMT-03:00 Jason Everling
>> <jeverling at bshp.edu <mailto:jeverling at bshp.edu>>:
>>
>> I can say that the workaround works quite well! Have
>> been using it for almost a year now in production
>> without issue and without having any "missed"
>> notifications not going out.
>>
>> Thanks Pavol for adding that functionality sometime
>> ago as it has proved invaluable for us!
>>
>> JASON
>>
>> On Fri, Aug 19, 2016 at 1:11 PM, Pavol Mederly
>> <pavol.mederly at evolveum.com
>> <mailto:pavol.mederly at evolveum.com>> wrote:
>>
>> Hello Rodrigo,
>>
>> please see
>> https://jira.evolveum.com/browse/MID-2237
>> <https://jira.evolveum.com/browse/MID-2237> for a
>> discussion on this requirement. Although it is
>> not implemented yet, there is a simple workaround
>> described there. It is based on using
>> /event.isRelatedToItem/ method.
>>
>> Best regards,
>> Pavol
>>
>> ------------------------------------------------------------------------
>> *From: *"Rodrigo Yanis" <ryanis at identicum.com
>> <mailto:ryanis at identicum.com>>
>> *To: *midpoint at lists.evolveum.com
>> <mailto:midpoint at lists.evolveum.com>
>> *Sent: *Friday, August 19, 2016 7:20:11 PM
>> *Subject: *[midPoint] - Manual tasks notifications
>>
>>
>> Hello everyone,
>>
>> We have the need to push a notification only when
>> a particular attribute is changed in a user in
>> midPoint. This attribute would be linked to a set
>> of roles that the user would inherit in midPoint
>> only, hence the need to inform a sysadmin to
>> perform a manual role redefinition in connected
>> applications.
>>
>> Is it possible to trigger a notification like
>> this? Should this be done in the context of a
>> midPoint resource?
>>
>> Thank you in advance!
>>
>> *Rodrigo Yanis.*
>> Identicum S.A.
>> Jorge Newbery 3226
>> Tel: +54 (11) 4824-9971
>> <tel:%2B54%20%2811%29%204824-9971>
>> ryanis at identicum.com <mailto:ryanis at identicum.com>
>> www.identicum.com <http://www.identicum.com/>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> <mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>> <http://lists.evolveum.com/mailman/listinfo/midpoint>
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> <mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>> <http://lists.evolveum.com/mailman/listinfo/midpoint>
>>
>>
>>
>>
>>
>> CONFIDENTIALITY NOTICE:
>> This e-mail together with any attachments is
>> proprietary and confidential; intended for only the
>> recipient(s) named above and may contain information
>> that is privileged. You should not retain, copy or
>> use this e-mail or any attachments for any purpose,
>> or disclose all or any part of the contents to any
>> person. Any views or opinions expressed in this
>> e-mail are those of the author and do not represent
>> those of the Baptist School of Health Professions. If
>> you have received this e-mail in error, or are not
>> the named recipient(s), you are hereby notified that
>> any review, dissemination, distribution or copying of
>> this communication is prohibited by the sender and to
>> do so might constitute a violation of the Electronic
>> Communications Privacy Act, 18 U.S.C. section
>> 2510-2521. Please immediately notify the sender and
>> delete this e-mail and any attachments from your
>> computer.
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> <mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>> <http://lists.evolveum.com/mailman/listinfo/midpoint>
>>
>>
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>> <http://lists.evolveum.com/mailman/listinfo/midpoint>
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>> <http://lists.evolveum.com/mailman/listinfo/midpoint>
>>
>>
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>> <http://lists.evolveum.com/mailman/listinfo/midpoint>
> _______________________________________________ midPoint mailing
> list midPoint at lists.evolveum.com
> <mailto:midPoint at lists.evolveum.com>
> http://lists.evolveum.com/mailman/listinfo/midpoint
> <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/20160823/ad7d217e/attachment.htm>
More information about the midPoint
mailing list