When instance level `duo_features_enabled` value changes, all subgroup/project values should change
Summary
When an admin updates Duo features to be default on or default off, all groups and projects in the instance should have their settings values updated to match.
More context
We already cascade values from groups to projects: !145876 (merged)
But we do not cascade from application settings to projects. The cascade works for groups in many cases because any root-level groups that have the duo_features_enabled
setting value set to nil
will inherit the new value from application_settings
. But if a group has set the setting at any point, inheritance will not work.
And, inheritance from application settings will never work for projects because they do not have a default value of nil
for duo_features_enabled
.
This is unexpected behavior. As an admin of a SM instance, I would expect the duo_features_enabled
setting to propagate not just to groups but to projects as well.
This bug is for turning the settings to "default on" or "default off". When duo settings are "always off" at the application settings level, that cascades to groups and projects as expected
Definition of done
- As an admin of a GitLab instance, when I update the value of
duo_features_enabled
from "default on" to "default off":- All groups in the instance have
duo_features_enabled
set tofalse
- All projects in the instance have
duo_features_enabled
set tofalse
(this will happen as a side effect of the existing logic we have for when group settings change)
- All groups in the instance have
- As an admin of a GitLab instance, when I update the value of
duo_features_enabled
from "default off" to "default on":- All groups in the instance have
duo_features_enabled
set totrue
- All projects in the instance have
duo_features_enabled
set totrue
(this will happen as a side effect of the existing logic we have for when group settings change)
- All groups in the instance have