New customer purchase workflow prevents purchases on groups with expired subscriptions
Summary
The new customer purchase workflow that occurs on the GitLab.com side (rather than customers.gitlab) prevents users from selecting a group to apply a new purchase on if that desired group currently has an expired subscription which is still within the 14-day grace period. For example, purchasing a new Bronze plan to replace the expired Gold plan is not possible.
Steps to reproduce
Have a group with an expired subscription, but which is still within the grace period before the system automatically downgrades the group to Free. Attempt a new purchase workflow from customerDot, which redirects to gitlab.com/susbcriptions. The dropdown when choosing a group for the new subscription is not populated with desired group
What is the expected correct behavior?
Customer should be able to make a new purchase for a group with an expired subscription
Relevant logs and/or screenshots
- Customer has 3 groups, one of which is currently on Gold with expired subscription:
- From customers.gitlab.com, when attempting to purchase a new plan, the workflow redirects to
gitlab.com/subscriptionsand the form only displays 2 groups, neither are the desired group:
- There are no available plans for purchase when viewing group billing page:
However, Circumventing the new process (see below) shows the group with the expired subscription as available for applying a new purchase:
Workarounds
Circumventing the redirect to gitlab.com and going directly to the customerDot URL and entering the plan_id allows the purchase to continue from customers.gitlab.com, and the group is available. For example, bronze plan id 2c92a0ff5a840412015aa3cde86f2ba6:
https://customers.gitlab.com/subscriptions/new?plan_id=2c92a0ff5a840412015aa3cde86f2ba6&transaction=create_subscription
Purchase workflow can then continue directly from customerDot.
Alternatively, manually downgrading the group to free should also allow the new purchase to proceed.