Investigate and document the flows for the following user settings and their associated state (permission) changes:
Archive User
Activate User
Block User
Reset password
Detect other services with inactive users who may be in the same situation, but have not yet encountered this issue, so we can correct the underlying issues before they become visible to a service owner.
Why are we doing this?
We had an incident that started when a service owner needed to remove a user from their service's team list. The option to remove the user was not available to them, nor to any platform admins at CDS.
The Inactive database flag, for this user, had been manually set to true. This put them in a state that they should not have been in that our UI did not "anticipate", thus creating a confusing and unclear scenario for the service owner.
What are we building
A better and documented understanding of what it means to reset a user's password, archive, block, activate a user.
The value added
A better understanding of these user states will allow us to better anticipate and understand user issues, and provide us with the insights we need to make Notify more robust, and user friendly.
Acceptance Criteria** (Definition of done)
[ ] We better understand the various states that a User can be in
[ ] Documentation has been created that can be referred to (diagrams and a spreadsheet/table for status for different scenarios)
[ ] Other services that could be affected by this issue have been identified and the underlying data has been corrected
Description
Investigate and document the flows for the following user settings and their associated state (permission) changes:
Detect other services with inactive users who may be in the same situation, but have not yet encountered this issue, so we can correct the underlying issues before they become visible to a service owner.
Why are we doing this?
We had an incident that started when a service owner needed to remove a user from their service's team list. The option to remove the user was not available to them, nor to any platform admins at CDS.
The
Inactive
database flag, for this user, had been manually set to true. This put them in a state that they should not have been in that our UI did not "anticipate", thus creating a confusing and unclear scenario for the service owner.What are we building
A better and documented understanding of what it means to reset a user's password, archive, block, activate a user.
The value added
A better understanding of these user states will allow us to better anticipate and understand user issues, and provide us with the insights we need to make Notify more robust, and user friendly.
Acceptance Criteria** (Definition of done)