[midPoint] Assign approval work item to role
Pavol Mederly
mederly at evolveum.com
Tue Jul 28 10:58:19 CEST 2015
Hello Илья,
this is definitely a bug - or, more precisely, it is a preliminary
implementation.
Perhaps the serious implementation should throw away support for role
assignments altogether, and instead of looking at org assignments, it
should consider parentOrgRef reference. That one is computed by the
model, and contains only valid assignments. (With regards to
administrative status, time validity, conditions if org membership is
induced e.g. by roles, and so on.)
And the next level should be - perhaps configurable - looking at "grand
parent" orgs, "grand grand parent" orgs, etc. (I.e. parents of
parentOrgRef, and their parents, recursively.)
It is not a big change, actually. Maybe an hour or two of work,
including testing. But the release of 3.2 is a few days ahead, and we
have a lot of work until that :(
You can implement it yourself and submit a patch, if you wish.
Best regards,
Pavol
> Hi Pavol,
>
> I looked into the WorkItemProvider. createQueryForTasksRelatedToUser()
> method implementation, particularly MiscDataUtil.getGroupsForUser(),
> and noticed that this method does not respect activation parameters of
> the assignment. Is this a bug or a feature? What exactly must be
> affected by activation settings and what mustn’t?
>
> *From:*midPoint [mailto:midpoint-bounces at lists.evolveum.com] *On
> Behalf Of *Дорофеев Илья
> *Sent:* Monday, July 27, 2015 2:24 PM
> *To:* midPoint General Discussion
> *Subject:* Re: [midPoint] Assign approval work item to role
>
> Hi Pavol,
>
> Many thanks for your in-depth response. Now the subject has become
> much clearer to me. Earlier I didn’t notice "Work items claimable by
> me" section and thought that assignees are calculated immediately at
> the moment the work item is created. Now it turns out that we have a
> list of possible approvers synchronized with actual membership of a
> person in a role, which, in turn, is pretty cool J.
>
> *From:*midPoint [mailto:midpoint-bounces at lists.evolveum.com] *On
> Behalf Of *Pavol Mederly
> *Sent:* Monday, July 27, 2015 2:01 PM
> *To:* midpoint at lists.evolveum.com <mailto:midpoint at lists.evolveum.com>
> *Subject:* Re: [midPoint] Assign approval work item to role
>
> Ilija,
>
> back from the vacation.
>
> Created Org "wheel" with two users: admin1, admin2 (both having
> Superuser role, not to bother with security).
> Created role "testrole" where approver == wheel.
> Attempted to create "testuser" with assigned "testrole".
>
> Work item was created, where candidate is wheel (org).
>
> imap://mederly@mail.evolveum.com:993/fetch%3EUID%3E/INBOX%3E8765?header=quotebody&part=1.1.2&filename=image001.png
> After logging in as "admin1" - no "My work items", but one "Work items
> claimable by me":
>
> imap://mederly@mail.evolveum.com:993/fetch%3EUID%3E/INBOX%3E8765?header=quotebody&part=1.1.3&filename=image002.png
>
> It can be claimed and released back, or directly processed.
>
> Implementation is such that this Activiti Task is created like this -
> see the second row:
>
> imap://mederly@mail.evolveum.com:993/fetch%3EUID%3E/INBOX%3E8765?header=quotebody&part=1.1.4&filename=image003.png
>
> I.e. its candidate group is in the form of "org:oid" where oid is the
> midPoint OID of the "wheel" org.
>
> For implementation, see e.g.
> - PrepareApprover.execute (called from ItemApproval BPMN process) -
> maps approverRef of type Role or Org to "role:oid" or "org:oid"
> Activiti candidate group names
> - and then see ItemApproval BPMN process, userTask
> id="loopLevels.loopApprovers.approve.withGroups" (lines 123-131)
> - WorkItemProvider. createQueryForTasksRelatedToUser (searching for
> work items)
>
> Hope this helps,
> Pavol
>
> On 22. 7. 2015 9:15, Дорофеев Илья wrote:
>
> Pavol,
>
> Thanks for the answer. I am sorry but the assignment to members of
> an org. unit didn’t work either. None of the members of the org.
> unit are offered a work item. I looked through the code and didn’t
> find any mentions of mapping between midPoint and Activiti groups.
> So, when an Activiti task is assigned to a candidate group
> org:c96bf133-10f6-4ed0-9c88-cb3c69bb27ec, the Activiti engine
> doesn’t really know the actual users of the group, and the task is
> basically assigned to no one.
>
> Could you show me that piece of code responsible for this behavior
> in case I’m wrong?
>
> Ilya
>
> *From:*midPoint [mailto:midpoint-bounces at lists.evolveum.com] *On
> Behalf Of *Pavol Mederly
> *Sent:* Tuesday, July 21, 2015 4:44 PM
> *To:* midPoint General Discussion
> *Subject:* Re: [midPoint] Assign approval work item to role
>
> Ilya,
>
> I've implemented this quite a long ago, so I'm having a little
> trouble remembering the current status. ;)
>
> But as described here:
> https://wiki.evolveum.com/display/midPoint/Current+status+and+future+plans:
>
> /#7: Ability to define approver not as an individual only, but
> also as a member of an org. unit; allowing to claim/release a work
> item. Currently this feature is limited to "direct" members, i.e.
> not to members of subordinate org. units. (Temporarily, it is
> possible to use a role as an approver as well, but this also
> applies only to users that have directly assigned this role - and
> perhaps support for this will be dropped in the future, see the
> following discussion on roles and orgs
> <https://wiki.evolveum.com/display/midPoint/Roles+and+Orgs>.)/
>
> So, the assignment to members of an org. unit works, but in a
> special mode: each of the members is offered the work item. (I.e.
> not assigned directly.) He/she may claim it, and work on it.
>
> As written above, I would suggest not using roles for this, but
> org. units instead. (Note that org. unit is a very general term.
> It may well correspond to an arbitrary group of people.)
>
> Hope this helps,
>
> Pavol
>
> ------------------------------------------------------------------------
>
> *From: *"Дорофеев Илья" <i.dorofeev at solarsecurity.ru
> <mailto:i.dorofeev at solarsecurity.ru>>
> *To: *"midPoint General Discussion" <midpoint at lists.evolveum.com
> <mailto:midpoint at lists.evolveum.com>>
> *Sent: *Tuesday, July 21, 2015 12:24:56 PM
> *Subject: *[midPoint] Assign approval work item to role
>
> Hi,
>
> I have just come across a problem of assigning approval work item
> to a role.
>
> <role>
>
> <approverRef oid="1ae3ab25-188f-4685-a073-fe522c55e057"
> type="c:RoleType"><!-- resource_owner --></approverRef>
>
> </role>
>
> I expected that the created workitem(s) would be assigned to all
> the users included in the ‘resource_owner’ role. Is this not
> implemented yet?
>
> Regards, Ilya
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
> 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
>
>
>
> _______________________________________________
> 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/20150728/336dbd9e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 13661 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20150728/336dbd9e/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 12189 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20150728/336dbd9e/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 6278 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20150728/336dbd9e/attachment-0002.png>
More information about the midPoint
mailing list