## Problem to solve Discerning how and when projects are deleted can be difficult to understand. ## Proposal > No major functionality will be changing. Just small tweaks to streamline the user journey, and reducing the opportunity for ambiguous conflicts. **Admin Area** - Rename field {-Default project deletion protection-} to {+Allowed to delete projects+} - Use radio buttons instead of checkbox - Combine {-Default delayed project deletion-} and {-Default deletion delay-} into {+Deletion protection+} - Use radio buttons to change state - Use a dropdown button to change selection - ✔️ groups and projects - groups only - Use an input counter that can't be set to ≤ `0` - When set to **none, delete immediately**, hide the radio buttons from groups and adjust the help text <details><summary>Before/After</summary> | Before | After | | ------ | ------ | | || </details> **Groups** - Move setting outside of **Permissions** into its own group {+Deletion protection+} - Change the description based on who is allowed to delete projects - Use radio buttons to change selection rather than a checkbox - 🔘 Keep project for X days - ⚪️ None, delete immediately - When enforcement is ☑️ for subgroups, disable the radio buttons and show a locked setting. <details><summary>Before/After</summary> | Before | After | | ------ | ------ | ||| </details> [Open Figma →](https://www.figma.com/file/6rqigCtnDjiWFGFeahDuJO/%23348332-Revamp-project-deletion-setting-options-for-clearer-interpretation?node-id=1%3A51) | Enforced by group | Set to none in Admin Area | | ------ | ------ | |  |  | ## What does success look like, and how can we measure that? Users should be able to understand what specific settings are impacting and configure their environments easily to match their expectations. Measurement (proposal): Uptick in the number of gitlab~2278657 users keeping deletion protection enabled. ## Documentation - `doc/user/admin_area/settings/visibility_and_access_controls.md`, [docs page](https://docs.gitlab.com/ee/user/admin_area/settings/visibility_and_access_controls.html#default-deletion-delay), [docs page](https://docs.gitlab.com/ee/user/admin_area/settings/visibility_and_access_controls.html#default-delayed-project-deletion) - `doc/api/projects.md` - `doc/user/admin_area/settings/visibility_and_access_controls.md`, [docs page](https://docs.gitlab.com/ee/user/admin_area/settings/visibility_and_access_controls.html#restrict-project-deletion-to-administrators) ## References <details><summary>Solution Validation (Synthesis)</summary> 3 unmoderated usability tests were conducted in UserTesting to validate the ease-of-use associated with the design decisions. - [Part 1](https://app.usertesting.com/workspaces/509645#!/study/3863487/sessions) - [Part 2](https://app.usertesting.com/workspaces/509645#!/study/3867533/sessions) - [Part 3](https://app.usertesting.com/workspaces/509645#!/study/3869513/sessions) After testing with 15 participants in total, it was clear the tasks were easily completed. However, the ability to switch back to a `null` state was still confusing to users. This will be removed from the scope of this issue and followed-up with its own research in https://gitlab.com/gitlab-org/gitlab/-/issues/350087. </details> ## Implementation plan 1. ~backend Add a new `delayed_group_deletion` application setting https://gitlab.com/gitlab-org/gitlab/-/issues/352959 :three: ~"workflow::ready for development" %"14.10" 1. ~frontend Revamp admin area deletion protection settings https://gitlab.com/gitlab-org/gitlab/-/issues/352960 :two: ~"workflow::blocked" by `1.` 1. ~frontend Revamp group deletion protection settings https://gitlab.com/gitlab-org/gitlab/-/issues/352961 :three: ~"workflow::blocked" by `1.`