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_enabledfrom "default on" to "default off":- All groups in the instance have
duo_features_enabledset tofalse - All projects in the instance have
duo_features_enabledset 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_enabledfrom "default off" to "default on":- All groups in the instance have
duo_features_enabledset totrue - All projects in the instance have
duo_features_enabledset 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