[midPoint] - Manual tasks notifications
Pavol Mederly
mederly at evolveum.com
Mon Aug 22 09:14:39 CEST 2016
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
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
> http://lists.evolveum.com/mailman/listinfo/midpoint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20160822/ff639d82/attachment.htm>
More information about the midPoint
mailing list