Defect #2770

Synchronization of contract slices doesn't cause provisioning to systems (=> changes may not be propagated)

Added by Alena Peterová 6 months ago. Updated 6 months ago.

Vít Švanda
Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected versions:


Tested on 10.8.2.
  • We fill the name of work position to some AD attribute
  • A user has a contract controlled by time slices (screenshot: before_sync.png)
  • A new slice is added in the source system and this slice will be the currently used slice.
    (Alternatively: currently used slice is updated in the source system)
  • The slice causes some change to the contract, in our case change of the work position
  • There is no provisioning caused by the synchronization (provisioning_archive.png) => the change of the work position is not propagated to the end systems => AD contains old values, even if IdM contains new values

Shortly: Entity events coming from the task ClearDirtyStateForContractSliceTaskExecutor have the property skip_provisioning=true.

  • If the slice causes that the identity is a new manager / stops to be a manager, then the subordinates are not provisioned => they have old values of "manager" attribute in AD
  • If the synchronization causes some change in roles for the AD system, the provisioning is caused by recalculation of automatic roles. That's probably why we don't encounter this situation in our projects more often.
  • If the new slice is valid in the future, then it is handled by SelectCurrentContractSliceTaskExecutor at the start of its validity. This task causes provisioning. => Changes made in the HR systems early enough are propagated in due time
  • The synchronization log contains the following message (probably not really important):
    Warning - select corrent contract slice is not executed correctly, Returned operation result is null. Ended in [2021-04-20T13:44:56.545299+02:00[Europe/Prague]].

Attached can be used as a system for synchronization of contract slices together with the following data:

\c hrdata
create table contractsslices (slice date, slice_id varchar, personalnumber varchar, contract_id varchar, validfrom timestamp, workposition varchar);
alter table contractsslices owner to czechidm;
insert into contractsslices values ('2021-04-01','00001_2021_04_01', '2000','00001', '2021-04-01', 'Department 1');
-- newly added contract slice which will be processed by the synchronization (change of the department)
insert into contractsslices values ('2021-04-20','00001_2021_04_20', '2000', '00001', '2021-04-01', 'Department 2');

provisioning_archive.png (33.2 KB) provisioning_archive.png Alena Peterová, 04/20/2021 06:14 PM
entity_events.png (116 KB) entity_events.png Alena Peterová, 04/20/2021 06:14 PM
sync_slices.png (85.2 KB) sync_slices.png Alena Peterová, 04/20/2021 06:14 PM
after_sync.png (68.7 KB) after_sync.png Alena Peterová, 04/20/2021 06:14 PM
before_sync.png (61.7 KB) before_sync.png Alena Peterová, 04/20/2021 06:14 PM (61.8 KB) Alena Peterová, 04/20/2021 06:22 PM
task_scheduler.png (84.1 KB) task_scheduler.png Alena Peterová, 04/20/2021 06:33 PM


#1 Updated by Alena Peterová 6 months ago

  • Description updated (diff)

Also note about subordinates - that's how we found out this thing

#2 Updated by Vít Švanda 6 months ago

  • Status changed from New to In Progress

#3 Updated by Vít Švanda 6 months ago

  • Target version set to 10.8.3

#4 Updated by Vít Švanda 6 months ago

  • Target version changed from 10.8.3 to 10.8.4

#5 Updated by Vít Švanda 6 months ago

  • % Done changed from 0 to 90

Thanks for very detailed and correct bug report. I fixed this bug by your way.

The cause of this error are parameters that are passed from the slice to the contract and then to the identity. One of them is the contains skip of provisionig (from sync).

After detailed debugging and testing, I think the skip was not intentional and should be removed. During testing, I found that each changed section triggers provisioning identity now. I consider this to be acceptable behavior.

I made a test for this.


#6 Updated by Vít Švanda 6 months ago

  • Status changed from In Progress to Needs feedback
  • Assignee changed from Vít Švanda to Radek Tomiška
  • Affected versions Onyx (9.3.3) added

#7 Updated by Vít Švanda 6 months ago

  • Affected versions deleted (10.8.2)

#8 Updated by Radek Tomiška 6 months ago

  • Status changed from Needs feedback to Closed
  • Assignee changed from Radek Tomiška to Vít Švanda
  • % Done changed from 90 to 100

I did test and code review, it works, thx!

Also available in: Atom PDF

Go to top