Project

General

Profile

Actions

Defect #1734

closed

Identity is incorrectly valid

Added by Patrik Stloukal almost 5 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Vít Švanda
Category:
Contractual relationship
Target version:
-
Start date:
06/27/2019
Due date:
% Done:

100%

Estimated time:
Affected versions:
Owner:

Description

We have situation, where we have on production 15 Vaild users, but all of them have expired contract.

So I was testing validity of identity by simulating identity's life with time slices (based on real data). And I ended up with identity, which was incorrectly VALID like 15 real users in production. I was testing it on 27.06.2019
I was testing this on new DB and downloaded build IdM 9.5.1.2

But normal changing of time slices would be much more time consuming (like on virtual server for several days), on this test I did changes of time slices in DB., based on how it would looks like in normal situation.
If I made incorrect assumption, then I am sorry.


Files

testTimeSlice.png (122 KB) testTimeSlice.png Patrik Stloukal, 06/27/2019 08:45 AM

Related issues

Related to IdStory Identity Manager - Defect #1822: HrEndContractProcess and HrEnableContractProcess process wrong items (some duplicate, some too late)ClosedRadek Tomiška08/26/2019

Actions
Actions #1

Updated by Patrik Stloukal almost 5 years ago

I made theese steps:
1)
I created identity hrTest with personal number 40451. And deleted Default contract. Then I created time slices:
1. time slice:
valid from 01.06.2019
valid till 14.11.2019
contract valid from 01.06.2019
contract valid till 15.11.2019

2. time slice
valid from 15.11.2019
valid till 30.05.2020
contract valid from 01.06.2019
contract valid till 15.11.2019

3. time slice
valid from 31.05.2020
valid till null
contract valid from 01.06.2019
contract valid till 31.05.2020

run LRTs one after another in this sequence HrEnableContractProcess, HrEndContractProcess, SelectCurrentContractSliceTaskExecutor

identity is VALID
contrakt is VALID

2)
Next I want to simulate the march of time, but if I changed time in GUI it will be afflicted by other processes in re-save identiy / contract.
So i changed times in DB (1,2):

1. time slice:
valid from 01.06.2019
valid till 26.06.2019
contract valid from 01.06.2019
contract valid till 27.06.2019

2. time slice
valid from 27.06.2019
valid till 30.05.2020
contract valid from 01.06.2019
contract valid till 27.06.2019

3. time slice
valid from 31.05.2020
valid till null
contract valid from 01.06.2019
contract valid till 31.05.2020

run LRTs one after another in this sequence HrEnableContractProcess, HrEndContractProcess, SelectCurrentContractSliceTaskExecutor

identity is VALID
contrakt is VALID

3) change in db:
1. time slice:
valid from 01.06.2019
valid till 25.06.2019
contract valid from 01.06.2019
contract valid till 26.06.2019

2. time slice
valid from 26.06.2019
valid till 30.05.2020
contract valid from 01.06.2019
contract valid till 26.06.2019

3. time slice
valid from 31.05.2020
valid till null
contract valid from 01.06.2019
contract valid till 31.05.2020

In this point I have to change even contract. Because I in this simulation make like it is next day. And in normal situation before this LRTs contract would be already invalid by time (contract's valid till in past). So i change contract's valid till to 26.06.2019.

run LRTs one after another in this sequence HrEnableContractProcess, HrEndContractProcess, SelectCurrentContractSliceTaskExecutor

identity is in LEFT state
contract is was valid in past

4) change in DB:
1. time slice:
valid from 01.06.2019
valid till 14.06.2019
contract valid from 01.06.2019
contract valid till 15.06.2019

2. time slice
valid from 15.06.2019
valid till 26.06.2019
contract valid from 01.06.2019
contract valid till 15.06.2019

3. time slice
valid from 27.06.2019
valid till null
contract valid from 01.06.2019
contract valid till 27.06.2019

run LRTs one after another in this sequence HrEnableContractProcess, HrEndContractProcess, SelectCurrentContractSliceTaskExecutor

identity is VALID
contract id VALID

5) change in DB:
1. time slice:
valid from 01.06.2019
valid till 14.06.2019
contract valid from 01.06.2019
contract valid till 15.06.2019

2. time slice
valid from 15.06.2019
valid till 25.06.2019
contract valid from 01.06.2019
contract valid till 15.06.2019

3. time slice
valid from 26.06.2019
valid till null
contract valid from 01.06.2019
contract valid till 26.06.2019

In this point I have to change even contract. Because I in this simulation make like it is next day. And in normal situation before this LRTs contract would be already invalid by time (contract's valid till in past). So i change contract's valid till to 26.06.2019.

run LRTs one after another in this sequence HrEnableContractProcess, HrEndContractProcess, SelectCurrentContractSliceTaskExecutor

identity is VALID
BUT contract was valid in past

Actions #2

Updated by Patrik Stloukal almost 5 years ago

Actions #3

Updated by Vít Švanda almost 5 years ago

  • Target version set to Rhyolite (9.7.0)
Actions #4

Updated by Patrik Stloukal almost 5 years ago

I tried simulate it with just contract and then with one time slice, but it did not work.
then i create these sql updates. Just do the first step from the previous comment and then these updates (plus between them run lrts) and before change corespondingly IDs.

@1.slice uuid_send('ab3576eb-4319-4864-8d9d-ecfcb14b6643'::uuid)
2.slice uuid_send('1d2a8a33-5429-4040-aeea-85916ae62f85'::uuid)
3.slice uuid_send('0dc5ca4b-33b5-4143-8af6-5326197b659e'::uuid)
contract uuid_send('b74ac474-5fa2-4565-836a-6b1ba3cbce3d'::uuid)
_____________________________________________________________________________________
2)

UPDATE public.idm_contract_slice
SET contract_valid_till=current_date, valid_from = current_date
WHERE id = uuid_send('1d2a8a33-5429-4040-aeea-85916ae62f85'::uuid);

UPDATE public.idm_contract_slice
SET contract_valid_till=current_date, valid_till = current_date -1
WHERE id = uuid_send('ab3576eb-4319-4864-8d9d-ecfcb14b6643'::uuid);

________________________________________________________________________________________
3)

UPDATE public.idm_contract_slice
SET contract_valid_till=current_date-1, valid_from = current_date-1
WHERE id = uuid_send('1d2a8a33-5429-4040-aeea-85916ae62f85'::uuid);

UPDATE public.idm_contract_slice
SET contract_valid_till=current_date-1, valid_till = current_date -2
WHERE id = uuid_send('ab3576eb-4319-4864-8d9d-ecfcb14b6643'::uuid);

UPDATE public.idm_identity_contract
SET valid_till = current_date -1
WHERE id = uuid_send('b74ac474-5fa2-4565-836a-6b1ba3cbce3d'::uuid);
__________________________________________________________________________________________
4)

UPDATE public.idm_contract_slice
SET contract_valid_till=current_date, valid_from = current_date
WHERE id = uuid_send('0dc5ca4b-33b5-4143-8af6-5326197b659e'::uuid);

UPDATE public.idm_contract_slice
SET contract_valid_till='2019-06-15', valid_from = '2019-06-15', valid_till=current_date-1
WHERE id = uuid_send('1d2a8a33-5429-4040-aeea-85916ae62f85'::uuid);

UPDATE public.idm_contract_slice
SET contract_valid_till='2019-06-15', valid_till='2019-06-14'
WHERE id = uuid_send('ab3576eb-4319-4864-8d9d-ecfcb14b6643'::uuid);
___________________________________________________________________________________________
5)

UPDATE public.idm_contract_slice
SET contract_valid_till=current_date-1, valid_from = current_date-1
WHERE id = uuid_send('0dc5ca4b-33b5-4143-8af6-5326197b659e'::uuid);

UPDATE public.idm_contract_slice
SET valid_till=current_date-2
WHERE id = uuid_send('1d2a8a33-5429-4040-aeea-85916ae62f85'::uuid);

UPDATE public.idm_identity_contract
SET valid_till = current_date -1
WHERE id = uuid_send('b74ac474-5fa2-4565-836a-6b1ba3cbce3d'::uuid);@

Actions #5

Updated by Vít Švanda almost 5 years ago

  • % Done changed from 0 to 30

I simulated that state. The problem here is the situation when in the queue of END contracts left our contract. However, I did not find a scenario how this could happen. In this scenario occures this problem because data is being edited directly in the DB, which can cause this condition (not removing the contract from the queue).

So far I do not see what could be fixed.

Actions #6

Updated by Vít Švanda almost 5 years ago

Potentially we could implement Radek's idea - clear the HrEndLrt queue from contract ended from other places.

Actions #7

Updated by Vít Švanda almost 5 years ago

  • Status changed from New to In Progress
Actions #8

Updated by Vít Švanda almost 5 years ago

  • Target version deleted (Rhyolite (9.7.0))
Actions #9

Updated by Vít Švanda almost 5 years ago

  • Status changed from In Progress to New
  • Target version set to Rhyolite (9.7.3)
Actions #10

Updated by Vít Švanda over 4 years ago

  • Target version changed from Rhyolite (9.7.3) to Rhyolite (9.7.5)
Actions #11

Updated by Vít Švanda over 4 years ago

  • Target version deleted (Rhyolite (9.7.5))
Actions #12

Updated by Radek Tomiška over 4 years ago

  • Related to Defect #1822: HrEndContractProcess and HrEnableContractProcess process wrong items (some duplicate, some too late) added
Actions #13

Updated by Radek Tomiška over 4 years ago

I hope is related to #1822, can be tested and closed.

Actions #14

Updated by Radek Tomiška over 4 years ago

  • Category set to Contractual relationship
  • Status changed from New to Closed
  • % Done changed from 30 to 100

Solved by #1872 (version 9.7.8).

Actions

Also available in: Atom PDF