Content
Updated by Pavel Balashou 5 days 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** deleteed status behaves like **locked** user
* User with **deleted** status is not shown in
* query results result
* API v3 v3\_API
* SCIM\_API
* ??? Question: should it also be removed from Admin UI: 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 of scope for this feature if** **###62107** **is not merged**
* User with **deleted** status is not shown in SCIM API <br>
**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**
* User with **deleted** status is not shown in
* query results
* API v3
* SCIM\_API
*
**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 of scope for this feature if** **###62107** **is not merged**
* User with **deleted** status is not shown in SCIM API