Skip to content

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

  1. 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 to false
    • All projects in the instance have duo_features_enabled set to false (this will happen as a side effect of the existing logic we have for when group settings change)
  2. 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 to true
    • All projects in the instance have duo_features_enabled set to true (this will happen as a side effect of the existing logic we have for when group settings change)
Edited by Jessie Young