MVC discussion for Instance, group and project-level integrations
The purpose of this issue is further break down the mass-integration epic and the design work that has been created in #208008 (closed)
Instance-level and project-level 13.4
MVC-1 - See details
-
Propagate the Instance level without allow_override and masking, propagate all the settings -
Add a confirmation modal on save at the Instance level (#238628 (closed)) -
Add the "Projects using custom settings" #218252 (closed) -
Add a tab view to all instance level integrations to support the "Projects using custom settings" view (needs issue)
Users that will benefit the most from this iteration are self-managed customers that require all their project integrations settings to be exactly the same. Here is a custom interview for context.
Value add
- Admin: Have the ability to see which projects chose to use their own custom settings
- Admin: Ability to enforce complete consistency of an integration's settings
- Admin/Project owner: Have the choice to use instance level settings as-is or overwrite them, similar to the existing Service Template functionality
Limitations
- If a project owner chooses the "Custom settings" option, they will not receive any settings updates from the admin
- Field values will not be masked, for example a token field set at the instance level will be visible to all project owners
Group level 13.5
MVC-2 - See details
- Introduce group settings with propagation
Users that will benefit the most from this iteration are gitlab.com users that need to enforce consistent integration settings across all project within their group.
Value add
- Empowering Group owners with the same abilities as Instance owners
Limitations
- Same as in MVC-1 only at the Group level
13.6
- 13.8
MVC-3 - Set custom value per individual field See details
Individual field overriding, masking and propagation using JSONB. This could require a lot of work, we need to resolve encryption &1443 (closed) and #26243, migrate data, and implement the JSONB resolution as described in this video about the Mass-Integration Database Design.
Users that will benefit the most from this iteration are self-managed and gitlab.com users with Enterprise level needs (ability to manage the settings for 1000+ projects) that required more granular controls.
Value add
- Giving Instance/Group owners more granular controls over which fields can be overridden and or masked
Limitations
- If a field is managed at the Instance level, a Group owner will not have the same controls over that field, meaning the top level parent has priority. This however may not be a limitation, more research needs to be done here.
- Any critical user stories that we may have missed?