Force associate: Allow admins to associate subscription without charge
Other work that could solve this issue
-
Based on the current requirements, we think that the completion of #5035 (closed) will close out this issue.
-
Also, the following epic would solve for Reseller Customer use case: Allow customers that purchased via Reseller to ... (&8941 - closed).
Summary
For various reasons, an admin may need to associate a subscription with a group, but without charging for additional seats.
Reasons:
- data out of sync: customersdot and gitlab.com has become out of sync - either the subscription details in customersdot don't match with gitlab.com or the subscription is not associated with the namespace on gitlab.com.
- out of sync data can be caused by: the gitlab.com user account linked to the customersdot account is no longer an owner in the group, so the connection to the namespace is lost
- manual intervention from support (mostly w.r.t extending trials at request from sales)
- sales-assisted purchase provisioning:
- sales-assisted purchases have to be provisioned manually for reseller customers
- some non-reseller customers ask for our help to provision and we would rather force associate than ask them to provision themselves if their current usage is higher than what they paid for.
- we do this because they would need to either decrease their usage or go back to sales to go through the whole purchase process just to apply the product they have already paid for. we're also safe knowing that sales will quote for trueups at renewal if overage occurs
Currently, Support does this through console using the force association function.
See also: &6828 and Review `Force reassociation` mechanizer function (&8425) for information on the use cases this feature will address.
Requirements
Updated based on #5035 (closed) (as it's likely closing out this issue):
- Customers are able to link a subscription to a namespace based on (see the proposal). This will push more self-service actions for our customers.
- Success message should confirm the action that was completed,
- The subscription association should reflect across all relevant systems: gitlab.com, Zuora, SFDC
- Ensure sufficient logs (see logs section)
- Cater to namespace states (see states below)
Outdated requirements:
An admin should be able to link a subscription to a namespace without triggering a billing actionProvide required field for task note
States
State details
1. Namespace with trial = yes
Expected: set trial = no, update namespace with subscription information (dates + plan), reset max seats to look at new subscription date range
- Namespace with subscription already linked
Expected: overwrite with new subscription information (dates + plan), reset max seats to look at new subscription date range
Logs
Errors/failures
Errors/failures:
- Expected errors/failures for this action should be documented (documentation location tbd)
- Errors/failures should be clear and include a recommendation on how to fix
- Errors should be logged and searchable in sentry/kibana (tbc)
Activity/History
- The following action details should be logged in history: - date + time - what action was performed - who performed the action (email address) - status (success/failure) with error message if failure - task notePermissions
Action should only be allowed for users with admin write permissions in customersdot.
All customers should be able to do this.
Support Priority Score: 20