Rename assignable property in User to be applicable
What does this MR do and why?
Renames assignable
property on User
to be applicable
since this property is about whether user is applicable for add-on rather than whether add-on an be assigned to them (add-on may not be assignable if all add-on seats are used up).
Related discussion around property rename: https://gitlab.com/gitlab-org/gitlab/-/issues/411954#note_1494438903
Note: The API changes are in progress, this MR is to make sure when the API is ready, frontend flows smoothly.
Related to #420010
Screenshots or screen recordings
How to set up and validate locally
-
Customers Dot needs to be setup in order to view the billing page for a group
-
Start GDK in SaaS mode
GITLAB_SIMULATE_SAAS=1 gdk start
-
Create a Group
-
Enable
enable_hamilton_in_usage_quotas_ui
FF (globally, or for your group) -
Buy a Subscription for your group from
Settings
>Billing
-
Visit
/groups/<your-namespace-name>/-/usage_quotas#seats-quota-tab
-
Purchase add-on for namespace
# Get the desired namespace namespace = Namespace.last # Create an add-on add_on = GitlabSubscriptions::AddOn.find_or_create_by!(name: "code_suggestions") {|e| e.description = "Test"} # Purchase add-ons for the namespace add_on_purchase = GitlabSubscriptions::AddOnPurchase.create!( add_on: add_on, namespace: namespace, expires_on: 1.month.from_now, quantity: 2, purchase_xid: 'A-S0001' )
-
Add this snippet here to enable add-on assignment. This enables the add-on assignment for the first user in the list (as per
applicable
value).state.members[0].add_ons = { assigned: [], applicable: [{ name: 'CODE_SUGGESTIONS' }] };
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.