Spike: Better tooling for Support to create/extend a trial for a Namespace with a previous trial
Problem
As explained in https://gitlab.com/gitlab-data/analytics/-/issues/19027#note_1678224100, we've found that the Support team needs to create or extend a trial for a Namespace that has had trials in the past. Because of logic in CDot preventing multiple trials, the Support team has to manually edit records to work around this restrictive logic and these workarounds have lead to data problems downstream as reported in https://gitlab.com/gitlab-data/analytics/-/issues/19027+.
When a trial is created for a Namespace, an entry is created in the trial_histories
table which has a uniqueness constraint on the gl_namespace_id
column. There is also a validation on Order
that prevents one from being created if a TrialHistory
record already exists for the gl_namespace_id
.
In the cases described in https://gitlab.com/gitlab-data/analytics/-/issues/19027#note_1678224100, Support updates the TrialHistory
for the existing gl_namespace_id
by adding a suffix XXXXX
to avoid the validation errors, which allows them to create a new trial Order.
Proposal
In this issue, let's explore ways to make this process of extending or creating a new Trial Order easier for Support. This will involve gathering more information from Support on their current process and determining if any of this can be automated in CDot Admin.
This may include updating the CDot logic for 1 trial per namespace. This validation on Order
prevents the Order
from being created if the namespace has a TrialHistory
entry. Perhaps this could be relaxed when the Order is being from Support?
Support Priority Score: (1, 2, 2, 3, -, 2, -, 2, -, 2, -) => 14