Prevent accidental access level changes when toggling project settings permissions
What does this MR do and why?
Key Terms
- Project Visibility Level: Whether a project is private, public, or internal
-
Project Feature Access Level: Refers to the access levels for individual features such as
issues,merge request, andanalytics
Changes
This MR prevents the accidental access level change when toggling project features access level.
When a feature toggle is re-enabled, we retain the previously selected dropdown value instead of defaulting to the last option.
Considerations
Unlike before, the "feature access level" for private projects won't be restricted to PROJECT_MEMBERS (10) anymore.
- This was never truly enforced since creating a new private project sets the feature access levels to
EVERYONE (20)by default. - It still shouldn't be possible to manually change the private project feature access levels between
PROJECT_MEMBER (10)andEVERYONE (20)once this merge request and #508449 (closed) has been merged.
References
Please include cross links to any resources that are relevant to this MR. This will give reviewers and future readers helpful context to give an efficient review of the changes introduced.
- Closes #499879 (closed)
- Related to https://gitlab.com/gitlab-org/gitlab/-/issues/492317#note_2163216308
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Screenshots or screen recordings
Notice how in the "before" recording, the access level changed to "Only Project Members" when toggles are re-enabled.
Before
Screen_Recording_2024-12-09_at_12.26.56_PM
After
Screen_Recording_2024-12-09_at_12.24.33_PM
How to set up and validate locally
Initial Setup
