Defect #2418
Updated by Alena Peterová almost 4 years ago
Version 10.4.1 Automatic roles by organizations are sometimes not recomputed after synchronization of contracts. It doesn't happen always, but in my scenario it was cca 50 %. * We have 3800 organizations, 6300 users, MS SQL repository * Tree node A has 3 automatic roles by structure (without recursion), the roles assign several systems (some directly, some are business roles). * Tree node B doesn't have any. * User "referent" has a contract on the tree node B. * Change the work position of the user from B to A in the HR system. * Run synchronization of contracts, which has the settings "After end, start the automatic role recalculation" checked. * After the synchronization finishes, the user's contract is already on the tree node A, but the user doesn't have any automatic role. The screenshots show what probably happened: The task ProcessSkippedAutomaticRoleByTreeForContractTaskExecutor didn't process any of the state flags AUTOMATIC_ROLE_SKIPPED. Because they were generated from the event IdmIdentityContract NOTIFY (created by sync) a second later than the task run. !scheduled_tasks.png! !entity_states_after_sync.png! There are 2 IdmIdentityContract events - probably the first one comes from updating the contract, the second from updating the contract's EAV (#2248). In some cases, processing of events was quick enough, so the first flag was generated before ProcessSkippedAutomaticRoleByTreeForContractTaskExecutor, processed by it and so the user had the roles after the synchronization. But it could make things worse - when the ProcessSkippedAutomaticRoleByTreeForContractTaskExecutor removed the automatic roles (in this case the change was from tree node A to B) and the role removal just met the provisioning from the Notify event, than the provisionings collided. Some variation of #2404 and #2350 occurred - for some systems, the Delete was not successful, for other system the provisioning queue is broken. archive was broken !roles_removing_met_update.png! I guess that if more contracts were processed by the synchronization, than something like this will happen with bigger probability for at least some of them. To sum up (sorry for the long ticket), the problems are two: * automatic roles by organizations aren't sometimes recomputed after synchronization. (It requires another run of ProcessSkippedAutomaticRoleByTreeForContractTaskExecutor) * if they are recomputed, it could collide with other provisionings coming from the same synchronization