Content
View differences
Updated by Pavel Balashou 9 months ago
**As** a SCIM client
**I want to** not see user right after successful SCIM deletion request
**Acceptance criteria**
* User.status must be set to **deleted** instead of **locked** when user deletion process has been initiated
* User with **deleted** status behaves like **locked** user
* User with **deleted** status is not shown in
* query results
* API v3
* SCIM API
* User with **deleted** status is shown in Admin users list before background worker completely delete the user record.
**Note for QA**
It is not easy to test this new status behavior without being able to disable/enabling background worker process(which is responsible for actual deletion).
I suggest that other developer should test it instead of a QA person.
**Technical notes**
* Checks for `user.locked?` must be modified to something like: `user.locked? || user.deleted?`
~~**Out **Out of scope for this feature if** **###62107** **is not merged**~~ merged**
* ~~User User with **deleted** status is not shown in SCIM API~~ API
**I want to** not see user right after successful SCIM deletion request
**Acceptance criteria**
* User.status must be set to **deleted** instead of **locked** when user deletion process has been initiated
* User with **deleted** status behaves like **locked** user
* User with **deleted** status is not shown in
* query results
* API v3
* SCIM API
* User with **deleted** status is shown in Admin users list before background worker completely delete the user record.
**Note for QA**
It is not easy to test this new status behavior without being able to disable/enabling background worker process(which is responsible for actual deletion).
I suggest that other developer should test it instead of a QA person.
**Technical notes**
* Checks for `user.locked?` must be modified to something like: `user.locked? || user.deleted?`
~~**Out
* ~~User