Project

General

Profile

Actions

Task #2260

closed

Advanced workflows for role criticality approval

Added by Vladimír Kotýnek over 4 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Petr Michal
Target version:
Start date:
05/18/2020
Due date:
05/31/2020
% Done:

100%

Estimated time:
Owner:

Description

The goal of this ticket is to implement two advanced workflows for role criticality.
The first one: the first approver is a manager for the contract; the second approver is a role guarantor of type A; the third approver is a role guarantor of type B
The second one: the first approver is a manager for the contract; the second approver is "a higher manager" for the contract (a mechanism how to determine the user should be implemented on the project); the third approver is a role guarantor of type A; the fourth approver is a role guarantor of type B

Actions #2

Updated by Vladimír Kotýnek over 4 years ago

  • Due date set to 05/31/2020
  • Assignee set to Petr Michal
Actions #3

Updated by Petr Michal over 4 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 20

I have prepared methods for all approval steps
- get guaratees by type
- get all guarantees
- get managers for contract where role was added
- get guarantees by projspec script

Next steps
- approval process
- workflow for added role approval

Actions #4

Updated by Petr Michal over 4 years ago

  • % Done changed from 20 to 40

Core WF logic is implemented for role assignment.

Next steps:
- Testing
- Tests
- Wf for assignment edit and removal

Actions #5

Updated by Petr Michal over 4 years ago

  • % Done changed from 40 to 60

I have completed the approval of change of valid dates and role attributes.
TODO: configuration, approval of automatic role, tests.

Actions #6

Updated by Petr Michal over 4 years ago

  • % Done changed from 60 to 80

After consultation of the requirements I did three workflows. Workflows do not approve creation or editing automatic roles.
Implementation: https://github.com/bcvsolutions/czechidm-extras/commits/michalp/2260-wf-for-role-approval

TODO: Tests, Edit names of some generated task.

For testing set application properties:
  • idm.sec.extras.wf.approval.customScript
  • idm.sec.extras.wf.approval.guaranteeTypeA
  • idm.sec.extras.wf.approval.guaranteeTypeB
Actions #7

Updated by Petr Michal over 4 years ago

  • % Done changed from 80 to 90
Actions #8

Updated by Roman Kučera over 4 years ago

I did code review and here are some notes. Most of them is just code style related things and typos.

DefaultExtrasWfApprovingService:48 add private access modifier
DefaultExtrasWfApprovingService:61 typo in guarenteeType should be guaranteeType :)
DefaultExtrasWfApprovingService:71 use english names for variables
DefaultExtrasWfApprovingService:72 use english names for variables
DefaultExtrasWfApprovingService:78 typo in guarenteeType should be guaranteeType :)
DefaultExtrasWfApprovingService:95 typo in guarenteeType should be guaranteeType :)
DefaultExtrasWfApprovingService:103 typo in guarenteeType should be guaranteeType :)
DefaultExtrasWfApprovingService:185 you can use method reference instead of lambda, just depend on personal preferences.

some method name has spaces before ( some don't, just use some auto format, so the code will have the same style

This condition is little confusing to me. Why is fallback to returning guarantees without type inside condition for type A? In case that Type is B but B has no guarantees you fill empty list into result. And in case that type is B but you have no guarantees for A or B you have no fallback for guarantees without type.

        if (guarenteeType.equals(APPROVE_BY_GUARANTEE_A)) {    
            if (!guaranteesA.isEmpty()) {
                result = guaranteesA;
            //if we do not have A type or B type guarantees. We return all guarantees (no type specified) 
            } else if (guaranteesA.isEmpty() && guaranteesB.isEmpty()) {
                result.addAll(getRoleGuaranteesByType(role, null));
            }
        }    

        if (guarenteeType.equals(APPROVE_BY_GUARANTEE_B)) {
            result = guaranteesB;
        }

DefaultExtrasWfApprovingService::guaranteeCheck I don't see any advantage of recalling other public methods from this "central" method. It would be better to call the public methods directly from WF. To change this you will need to do some changes to service and to WF and retest it.

One test failed on my local machine approvalByRoleGuranteeWithouGuaranteesByType otherwise coverage is nice.
ExtrasWfApprovingServiceTest.java:138
org.junit.ComparisonFailure: expected:<guaranteeIdentity[]> but was:<guaranteeIdentity[TypeA]>
Expected :guaranteeIdentity
Actual :guaranteeIdentityTypeA

Actions #9

Updated by Petr Michal over 4 years ago

I fixed and re-tested all comments from review. Condition for managers by type was explained on call.
Commit: https://github.com/bcvsolutions/czechidm-extras/commit/45e70a3a9ef4889af87a523325261052fa9bddb2

Please @kucerar can you make a final review?

Actions #10

Updated by Roman Kučera over 4 years ago

I checked the fixes and it looks good.
Even all tests are successful.
Thx, for this feature.

Actions #11

Updated by Petr Michal over 4 years ago

  • Status changed from In Progress to Resolved
  • Target version set to 2.3.0
  • % Done changed from 90 to 100
Actions #13

Updated by Peter Štrunc over 4 years ago

  • Status changed from Resolved to Closed

Released in 2.3.0

Actions

Also available in: Atom PDF