[midPoint] workflow - approvers approving - midpoint 3.5.1
Pavol Mederly
mederly at evolveum.com
Thu Apr 6 16:20:53 CEST 2017
Although setting useLegacyApproversSpecification to "never" is
recommended (after you decided to use policy rules to drive approvals),
it will most probably not help in this case. I'd suggest setting
useDefaultApprovalPolicyRules to "never" as well, although it will not
probably help.
The problem is deep in the midPoint code, where assignments are
evaluated. I have fixed it for 3.6, but it would be very hard to
backport the fix to 3.5.x.
What exactly are you trying to achieve? Maybe we could find some
alternative way.
Pavol Mederly
Software developer
evolveum.com
On 06.04.2017 16:02, Oskar Butovič - AMI Praha a.s. wrote:
> Hello Pavol,
>
> I Use policy rules. Follows example of one of my workflow roles.
>
> I have not set anything regarding legacy approvers and default
> approval policy rules. So this behaviour would stop if i set
> useLegacyApproversSpecification to never?
>
> ----------------------------------------------------------------------------
> <role
> xmlns:apti="http://midpoint.evolveum.com/xml/ns/public/common/api-types-3"
> xmlns:c="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
> xmlns:gen45="http://prism.evolveum.com/xml/ns/public/debug"
> xmlns:icfs="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3"
> xmlns:q="http://prism.evolveum.com/xml/ns/public/query-3"
> xmlns:ri="http://midpoint.evolveum.com/xml/ns/public/resource/instance-3"
> xmlns:t="http://prism.evolveum.com/xml/ns/public/types-3"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> oid="refused-meta-role" version="10"
> xmlns="http://midpoint.evolveum.com/xml/ns/public/common/common-3">
> <name>Refused Role</name>
> <inducement>
> <policyRule>
> <policyConstraints>
> <assignment/>
> </policyConstraints>
> <policyActions>
> <approval>
> <compositionStrategy>
> <order>2</order>
> </compositionStrategy>
> <approvalSchema>
> <level>
> <name>Automatic refusal</name>
> <approverExpression>
> <script>
> <code>
> log.warn("approving new role with undefined workflow for user: " +
> serachedUser.getName() + " automatically refusing.");
> //TODO zastavit approve process v 3.5.1 bude mozne pouzit
> outcomeIfNoApprovers
> return "workflow-refuser-user";
> </code>
> </script>
> </approverExpression>
> <evaluationStrategy>firstDecides</evaluationStrategy>
> </level>
> </approvalSchema>
> </approval>
> </policyActions>
> </policyRule>
> </inducement>
> </role>
> --------------------------------------------------------------------
>
>
> Best regards
>
> Oskar Butovič
>
> 2017-04-06 15:30 GMT+02:00 Pavol Mederly <mederly at evolveum.com
> <mailto:mederly at evolveum.com>>:
>
> Hello Oskar,
>
> how are your approvals set up? Do you use policy rules? What are
> your settings regarding legacy approvers and default approval
> policy rules? (see
> https://wiki.evolveum.com/pages/viewpage.action?pageId=24084761
> <https://wiki.evolveum.com/pages/viewpage.action?pageId=24084761>).
>
> Because, unfortunately, there are some problems with policy-based
> approvals for non-default relations in 3.5.x (see MID-3799, #1).
>
> Pavol Mederly
> Software developer
> evolveum.com <http://evolveum.com>
>
> On 06.04.2017 15:12, Oskar Butovič - AMI Praha a.s. wrote:
>> Hello everybody,
>>
>> I have stumbled across some strange approval workflow behaviour.
>>
>> When I am assigning roles with relation member everything works
>> fine, exactly as configured.
>>
>> But when i try to assign members weird stuff starts to happen.
>> Example:
>> - no or any workflow is configured for role via assigned metaroles
>> 1) I assign role R1 as approver to user U1
>> a) everything executes ok and role is assigned as approver
>> relation
>> 2) I assign role R1 as approver to user U2
>> a) midpoint ignores any workflow configured on metaroles
>> (approverExpressions are not executed at all)
>> b) approval task for user U1 is created.
>>
>> Why this might happen and how it could be changed? Part 2.b is
>> especially bothersome. It might cause that confusing workflow
>> notifications are sent during initial or following workflow
>> approver configuration.
>>
>> Best Regards
>>
>> Oskar Butovič
>>
>> --
>>
>> Oskar Butovič
>> solution architect
>>
>> gsm: [+420] 774 480 101 <tel:+420%20774%20480%20101>
>> e-mail: oskar.butovic at ami.cz <mailto:oskar.butovic at ami.cz>
>>
>>
>>
>> AMI Praha a.s.
>> Pláničkova 11
>> 162 00 Praha 6
>> tel.: [+420] 274 783 239 <tel:+420%20274%20783%20239>
>> web: www.ami.cz <http://www.ami.cz/>
>>
>>
>>
>> AMI Praha a.s.
>>
>>
>> AMI Praha a.s.
>> <http://www.ami.cz/reseni-a-sluzby/bezpecnost-dat/identity-management>
>>
>>
>> Textem tohoto e-mailu podepisující neslibuje uzavřít ani
>> neuzavírá za společnost AMI Praha a.s.
>> jakoukoliv smlouvu. Každá smlouva, pokud bude uzavřena, musí mít
>> výhradně písemnou formu.
>>
>>
>>
>> _______________________________________________
>> 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>
>
> --
>
> Oskar Butovič solution architect gsm: [+420] 774 480 101 e-mail:
> oskar.butovic at ami.cz <mailto:oskar.butovic at ami.cz>
>
>
>
> AMI Praha a.s. Pláničkova 11 162 00 Praha 6 tel.: [+420] 274 783 239
> web: www.ami.cz <http://www.ami.cz/>
>
>
>
> AMI Praha a.s.
>
> AMI Praha a.s.
> <http://www.ami.cz/reseni-a-sluzby/bezpecnost-dat/identity-management>
> Textem tohoto e-mailu podepisující neslibuje uzavřít ani neuzavírá za
> společnost AMI Praha a.s. jakoukoliv smlouvu. Každá smlouva, pokud
> bude uzavřena, musí mít výhradně písemnou formu.
>
> _______________________________________________
> 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/20170406/a0415f8f/attachment.htm>
More information about the midPoint
mailing list