IdStory Identity Manager

This will be implemented as new option for contract slice synchronization, but implementing with test is little bit complicated so I moved it on next version.

After consult I decided that I'm not implement new checkbox for contract slice synchronization, because contract slice synchronization use same settings as contract synchronization (to much reimplementing and it will be non backward compatible).

So when is checked run HR process after correctly ended synchronization. The task select current contract will be started. @Alca are you OK with the solution?

I implement executing select current contract slice after synchronization of contract slices correctly ended.

commit: https://github.com/bcvsolutions/CzechIdMng/commit/2458f9e871bd9349e4247f8a76caf2906a86b062 (branch: okopr/1291-select-current-contract)

Branch will be merged after release version 9.3.0

Tests is included.

Documentation will be also updated after will be released new version of documentation.

Documentation was added: https://wiki.czechidm.com/devel/documentation/synchronization/dev/contract-slice-sync#select_current_contract_slice

Please Vitek could you make a review? Thank you :)

Conclusion (goal of this ticket changed):

We need:

• Skip slice recalculation during sync (not implemented now). IdmContractSliceService.SKIP_RECALCULATE_CONTRACT_SLICE should be help, but this skip was not designed directly for this purpose, so beware on conseqences :-) (SelectCurrentContractSliceTaskExecutor as Alca descripted).
• Start recalculation of all slices (implemented in this task). Recalculation of silces is controlled by checbox for recalculation of HR processes (please extends the label for this information ... I know, same label will be see in contract sync and add big warning to changelog ... ).

We don't need this feature in version 9.4.0.rc.1, so please remove this from develop (sorry).

We need to release this feature as 9.3.2 and after that as 9.4.0.

The ticket will be solved in another hotfix (eq 9.3.3 or 9.4.0 final version).

Please move all changes in the ticket into some new branch.

Alena Peterová wrote:

Ondřej Kopr wrote:

The ticket will be solved in another hotfix (eq 9.3.3 or 9.4.0 final version).

Please not 9.4, we need this as hotifx for 9.3.x and we can't update to 9.4 yet.

Not problem, I create next hotfix 9.3.3. Thank you.

Solution was removed from 9.3.2: https://github.com/bcvsolutions/CzechIdMng/commit/7ff79878b946ea35715c2d43f3363a0e71694e1d

Commit was moved into branch: https://github.com/bcvsolutions/CzechIdMng/commits/hotfix-9.3.3

Today we tried simulate same problem on current develop:

• Synchronization 1:

• creates one new slice[ID:1] with validFrom 1.1. 2019 and validTill: infity
• after synchronization was added automatic roles by structure.

• We manually added two roles to newly created contract
• Synchronization 2:

• updates slice[ID:1] validTill: 3.1. 2019
• creates new slice slice[ID:2 ] with validFrom 1.1. 2019 and validTill: infinity
• after synchronization user still has all roles. In audit exits only infomation about validity change.

The problem descibes in ticket description:

One employee had contract to 30.9. The contract was prolonged to the next month. This information appeared in HR at last minute - on 30.9. So a new slice was created during the night 30.9.-1.10. The HR processes run after synchronization of slices, but before slices recalculation. So the user was disabled on 1.10., where he should be working. He was enabled again on 2.10., but that is too late.

Can't be simulated, because now doesn't exists skip for slice recalculation in synchronization. So for every slices is done recalculation during synchronization immediate (in future we probably need some skip :)). Task SelectCurrentContractSliceTaskExecutor exits only for recalculate existing slices, that expire during time, not from synchronization.

Question is, if we really need some changes for hotfix 9.3.3? Please could you test your scenarios?

OK, you're right that the roles aren't removed, only their validity is temporarily changed. But it's enough to delete and recreate the accounts :-(

• IdmIdentityRole is updated - validTill is set to the past (see audit_IdmIdentityRole_Modify.png)
• it causes IdmIdentityRole NOTIFY event, which runs identity-role-save-provisioning-processor (see entity_event_IdmIdentityRole.png)
• the processor starts account management just when all roles are invalid:
  

  2019-01-08 16:41:24.224  INFO 20773 --- [task-executor-2] e.b.i.c.a.e.AbstractEntityEventProcessor : Processor [identity-role-save-provisioning-processor]([acc]) start for [CoreEvent [type
  : eu.bcvsolutions.idm.core.model.service.impl.DefaultEntityEventManager$$Lambda$111/42994890@144e55ff, content: eu.bcvsolutions.idm.core.api.dto.IdmIdentityRoleDto [id= a9df673d-8f87-4abd-
  8efe-4510a259e916], properties: {idm:parent-event-id=null, idm:super-owner-id=46ed6b7e-efc1-4e88-abcb-4dbfdeb2156a, idm:parent-event-type=UPDATE, idm:root-event-id=null, idm:event-id=3fd8a
  d24-afcb-4ddf-abfd-db9b67ebd311, idm:priority=NORMAL, skipCheckAuthorities=true, idm:execute-date=null}]] with order [1000].
  ......
  2019-01-08 16:41:24.734  INFO 20773 --- [task-executor-2] e.b.i.c.m.s.i.DefaultEntityEventManager  : Publishing event [IdentityAccountEvent [type: DELETE, content: eu.bcvsolutions.idm.acc.dto.AccIdentityAccountDto [id= c46f5e87-0b09-43e7-9070-7a7300ef911c], properties: {deleteTargetAccount=true, forceDeleteOfIdentityAccount=false}]]
  

• ACM deletes the AccIdentityAccount, which deletes AccAccount, which causes provisioning Delete (see provisioning_archive.png - 3 accounts are deleted and later recreated, other 3 fall to account protection because the systems have it enabled).

Thank you for your test scenario, I started test it again and there is screenshots from my tests:

• STEP 1: I synchronized contract slice [id:1], after synchronization user recive automatic roles by treeStructure and I added one manually role:

• STEP 2: In end system I change validity for contract slice [id: 1] to past and then I create second one slice that is valid [id: 2]
• STEP 3: I start with new synchronization, during synchronization is actualized contract slice [id:1] and the slice and contract is now invalid (also roles), but account was deleted with also provisioning delete:

After synchronized the second slice [id:2] still exists roles with new validity and account with new provisioning operation was created:

So the main problem isn't with removing roles, but with remove account during this scenario. Do you agree?

Exactly, thank you for detailed screenshots.

Alena Peterová wrote:

Exactly, thank you for detailed screenshots.

I also thank you for confirmation, Now I try the skip recalculation for contract slices during synchronization.

Done, I implement new skip for contract slice recalculation (it is called set_dirty_state). Dirty state is calculated by new LRT ClearDirtyStateForContractSliceTaskExecutor. Task check all dirty states in entity states and then start recalculation for each slice.

Please Vitek could you make a review?

commit: https://github.com/bcvsolutions/CzechIdMng/commit/4e6872f94905a4efc43905381e4861801262b0bd
documentation: https://wiki.czechidm.com/devel/documentation/identities/dev/contractual-relationship-slice#slices_recalculation

Thank you for check. If you want I have prepared test data with test end system.

I tested this in C... project and it works fine, thanks.

Only strange thing is that the ClearDirtyStateForContractSliceTaskExecutor has different count of processed items, please see the screenshot.

The total amount is correct - it corresponds to the number of synchronized slices. But the count of processed items is sometimes lower.

EDIT: There must be something wrong with paging, because next run of ClearDirtyStateForContractSliceTaskExecutor processed the remaining 100 dirty flags and didn't process my 3 new dirty flags.

I did review and tested sync of slices.
It works well, so thanks for nice new recalculation with dirty flags. I think this is good way how generally would be recalculation realized.

- I found problem when current using slice was changed (contract validity) and validity From of slice was changed too. On end of my analysis, the problem is not in the bulk recalculation, but in recalculation of slice (one by one).
I fixed this in the commit:
https://github.com/bcvsolutions/CzechIdMng/commit/79e4692cc10c99676ac6b1aa4df8a98ed8b8498f