Use the Duo default group as Orbit billing group for team members
What does this MR do and why?
GitLab team members belong to many internal groups with Orbit, so they have no Orbit billing group until they pick one. When the promo gate is on, gitlab-org and gitlab-com both need the Orbit promo, so team members have at least two candidates. Then Orbit blocks their queries until they pick one.
- When a team member has not picked an Orbit billing group, GitLab uses the group saved as their default GitLab Duo group, if Orbit can bill that group.
- Otherwise GitLab uses
gitlab-com, if Orbit can bill it. Every team member is a direct member ofgitlab-com. - Customers keep the current behavior: one candidate is used automatically, and with more than one they pick.
The Orbit token, the "pick a group" prompt, the preferences dropdown, and the GraphQL field all get the new value. When a team member saves the preferences page, the group shown in the dropdown is stored as their pick, as it is today for a single candidate.
References
Relates to https://gitlab.com/gitlab-org/rust/knowledge-graph/-/work_items/328
How to set up and validate locally
Run GDK with GITLAB_SIMULATE_SAAS=1. Make the user a direct member of a top-level group with the path gitlab-com, and a member of a second group, both with Orbit on and a Premium or Ultimate plan.
# rails console
Gitlab::Com.expire_allowed_user_ids_cache
user = User.find_by_username('your-user') # fresh object, team membership is memoized
other_group = Group.find_by_full_path('your-other-group')
user.user_preference.update_columns(knowledge_graph_governing_namespace_id: nil, duo_default_namespace_id: nil)
user.user_preference.knowledge_graph_governing_namespace_with_fallback # => gitlab-com (was nil)
user.user_preference.update_column(:duo_default_namespace_id, other_group.id)
user.user_preference.knowledge_graph_governing_namespace_with_fallback # => your-other-groupMR acceptance checklist
Evaluate this MR against the MR acceptance checklist.