Refactor Security Config page after backend has been unified for CE & EE
What does this MR do and why?
This MR is meant to solve: #333113 (closed)
Before this MR the all of the configuration-data for the Security Configuration Page in FOSS was hardcoded on the client side. For the EE version the configuration-data for the Security Configuration Page was accumulated through the dynamic data object in the template and augmented with static data from the clientside code.
This MR changes the approach, it removes some of the hardcoded configuration-data for the Security-Configuration Page in FOSS and ensures that all of the Security-Config Pages no matter what license they're on are accumulated with data through the same approach as used in FOSS before. So we can eventually merge the .haml templates together and only have one template for the security configuration page no matter the license. This page will then be dynamically configured through the BE (this will be done in another MR).
Disclaimer: all of the Screenshots have been taken from the same project.
Screenshots or screen recordings (no visual changes)
FOSS/CE
| before | after |
|---|---|
 |
 |
ULTIMATE/EE
| before | after |
|---|---|
 |
 |
NO LICENSE/EE
| before | after |
|---|---|
 |
 |
How to set up and validate locally
- go to http://gitlab.localdev:3000/
USER/PROJECT/-/security/configuration for FOSS and EE without License and with ultimate License
The easiest way to swap between FOSS and EE is the env.runit file in the gdk root folder
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.