Warn about impacted escalation policies when members are deleted/leave
What does this MR do?
Related issue: #335546 (closed)
This MR updates the warning modals a user will see when trying to leave a group/project or delete a user. Escalation policies route alerts to either on-call schedules or directly to users. On-call schedules are already listed in the modal, so this MR adds a list of escalation policies which route alerts directly to users.
Changes
Backend:
- Adds support for escalation policies to the relevant internal APIs backend
- Limits listed on-call schedules to only the ones in which the user is an active participant
- De-dupes on-call schedules for a user in the group/project member list
Frontend:
- Renames
OncallSchedulesList
toUserDeletionObstaclesList
& all corresponding props/files frontend - Adds escalation policies to
UserDeletionObstaclesList
Screenshots or Screencasts
User removing self [leave modal] | Owner removing user [remove member modal] | Admin deleting [delete user modal] | Admin deleting with contributions [delete user modal] |
---|---|---|---|
Out of scope (will be other MRs)
- Deleting the escalation rules corresponding to the user
- Sending an email to project/group owners informing them of the change
How to setup and validate locally
- Removing yourself from a group/project
- Remove a user from a group/project (as owner/maintainer)
- Deleting user from instance (as admin)
Streamlined testing flow:
- Create a new account & logout (skip if you have a non-admin user already)
- Sign in as instance administrator
- Create a project
- Add new user as a developer on the project
- Setup on-call schedules & escalation policies which direct alerts to developer
- Navigate to members list to see removal modal
- Navigate to instance user list to see deletion modal
- Logout & Login as developer
- Navigate to members list to see removal modal
Does this MR meet the acceptance criteria?
Conformity
-
I have included changelog trailers, or none are needed. (Does this MR need a changelog?) -
I have added/updated documentation, or it's not needed. (Is documentation required?) -
I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?) -
I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?) -
I have self-reviewed this MR per code review guidelines. - [
🤞 ] This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines) -
I have followed the style guides. -
This change is backwards compatible across updates, or this does not apply.
Availability and Testing
-
I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.) -
I have tested this MR in all supported browsers, or it's not needed. -
I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.
Edited by Sarah Yasonik