giseldo/neodataset huggingface dataset:
[UX] IA Documentation for CustomersDot Support Admin Tool

This issue is to track efforts mapping the information hierarchy evaluation for the CustomersDot Support Admin Tool.

## :dart: Tasks

- [x] List all top-level navigation pages
- [x] Perform a high-level content inventory across each top-level page
- [x] Track themes and patterns of information across pages

## :art: Documentation

**[Mural Board](https://app.mural.co/t/gitlab2474/m/gitlab2474/1636995607862/095e896771fc71dad28d7ec5d185537cb5c12f0c?sender=tnoah8818)**

Story points: 3.0
Provide an alternative to using ngrok in local environments

### Problem

Related to https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2466 - after configuring Gitpod, we realised that `ngrok` was also needed for callout configuration.

According to https://about.gitlab.com/handbook/security/#other-servicesdevices

> Do not use tools designed to circumvent network firewalls for the purpose of exposing your laptop to the public Internet. An example of this would be using ngrok to generate a public URL for accessing a local development environment. 

### Proposal

Replace ngrok with an indirect proxy that forwards callouts from Zuora without the need to open a port in your computer. A few alternatives I thought of:

- Use https://gitlab.com/jameslopez/zsim to simulate the callouts API by querying the Zuora notifications API
- Create a proxy server that receives all dev callouts from Zuora and displays a copy & paste `curl` URL+payload we could replay in our local environment (Okta log in needed into the tool)

### Result

Safe local environments

Story points: 3.0
Replace references to created_at in displaying Purchase Date

### Problem

As described in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3556, in order to support Zuora Orders Harmonization in CustomersDot, we need to remove dependencies to Amendments in the `Product` class.  Amendments are currently used by `Product` objects to fetch `created_date` from the amendment used by [the `Product#created_at` method](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/ac33b9df3ddfd21f27eaad5e452d86394ecb7384/app/models/product.rb#L52).  This is used in CustomersDot [in various places for various reasons](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3556#note_690684649).

This issue in particular focuses on the usage of `created_at` for displaying the Purchase Date for a Subscription.

![purchases_after](/uploads/1d56c2a1e860a67ca4ddbb31fdd2895b/purchases_after.png)

[`ProductPresenter`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/94af84f55889ecbe0cbed93e38ac707fb96bce9a/app/presenters/product_presenter.rb#L23) - `created_at` is included in the set of product attributes. It was added in https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/1733, to show the purchase date of a product on the FE.

### Proposal

[To Be Determined]

In [this thread](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3556#note_692789137) we discussed a couple of ways to approach this.

* Proposed solution A: Remove purchased date from the display on subscription card in the FE, then remove reference from the presenter
* Proposed solution B: If solution A does not work, we could replace `created_at` with the original RPC created_date (same as the solution for CI minutes)

Update: As of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3556#note_692928087, we decided to keep purchase date information for now (unless it turns out to be a big problem to implement).  We'll go with proposed solution B.

### Result

A few less dependencies on `Product#created_at` which allows us to eventually remove amendment as a dependency altogether.

Story points: 0.0
Replace references to created_at in sorting products

### Problem

As described in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3556, in order to support Zuora Orders Harmonization in CustomersDot, we need to remove dependencies to Amendments in the `Product` class.  Amendments are currently used by `Product` objects to fetch `created_date` from the amendment used by [the `Product#created_at` method](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/ac33b9df3ddfd21f27eaad5e452d86394ecb7384/app/models/product.rb#L52).  This is used in CustomersDot [in various places for various reasons](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3556#note_690684649).

This issue in particular focuses on removing the usage of `created_at` in product sorting logic.

1. ~~[`Subscription#filtered_add_on_products`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/c7cc2593ba6b692acf619e603bec6d6124ef504e/app/models/subscription.rb#L581) - `created_at` is used to sort the array of products by the created date.~~  <-- This will be handled as part of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3656.
1. [`StorageService#purchased_storage_packs`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/5e9d586c623cf67708b5b22ba15fc2f329d6f725/app/services/gitlab/hosted_plans/purchased_add_ons/storage_service.rb#L33) - `created_at` is used to sort an array of storage products by the created date.

### Proposal

It was determined in [this thread](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3556#note_691793880) that a sufficient replacement for `created_at` would be to use the `effective_start_date` of the Rate Plan Charge on the Product.

### Result

A few less dependencies on `Product#created_at` which allows us to eventually remove amendment as a dependency altogether.

Story points: 1.0
Replace references to created_at from CI Minutes related logic

### Problem

As described in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3556, in order to support Zuora Orders Harmonization in CustomersDot, we need to remove dependencies to Amendments in the `Product` class.  Amendments are currently used by `Product` objects to fetch `created_date` from the amendment used by [the `Product#created_at` method](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/ac33b9df3ddfd21f27eaad5e452d86394ecb7384/app/models/product.rb#L52).  This is used in CustomersDot [in various places for various reasons](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3556#note_690684649).

This issue in particular focuses on removing the usage of `created_at` in code that relates to CI minutes usage and syncing.

1. [`Subscription#recently_purchased_ci_minutes`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/c7cc2593ba6b692acf619e603bec6d6124ef504e/app/models/subscription.rb#L531) - `created_at` is used to filter the CI minute pack products to those created/new since the last sync with GL.com.
1. [`CiMinutesService#execute`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/d871eb5b8f66de492890bdef5854ea53fa978890/app/services/gitlab/hosted_plans/purchased_add_ons/ci_minutes_service.rb#L34) - `created_at` is used to determine the time of the last ci minute purchase.
1. [`CiMinutesParamsGenerator#run`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/36d636f03b4d5ff1ba527ba4d559fc6e8e5b8785/lib/add_ons/ci_minutes_params_generator.rb#L19) - `created_at` is used to sync CI minutes info to GL.com. Specifically, for each CI minute product on the subscription, the expiration date is sent using the `created_at` date + 1 year.
1. [`Subscription#ci_minutes_packs`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/6abfda2cd85cca9af735b0f51b82bac3a7f75cd3/app/models/subscription.rb#L240) - `created_at` is used to sort the array of products by the created date.

### Proposal

It was determined in [this thread](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3556#note_691673940) that a sufficient replacement for `created_at` would be to use the `created_date` of the Original Rate Plan Charge on the Product.  [This comment](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3556#note_692693889) gives nice code examples and justification.

```
> ci_minute_packs.map { |p| p.rate_plan_charge.original.created_date }
=> ["2021-09-29T12:50:53.000-07:00", "2021-09-29T12:55:45.000-07:00", "2021-10-01T07:46:33.000-07:00"]
```

### Result

A few less dependencies on `Product#created_at` which allows us to eventually remove amendment as a dependency altogether.

Story points: 3.0
Replace references to created_at in Subscription#trueup_products

### Problem

As described in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3556, in order to support Zuora Orders Harmonization in CustomersDot, we need to remove dependencies to Amendments in the `Product` class.  Amendments are currently used by `Product` objects to fetch `created_date` from the amendment used by [the `Product#created_at` method](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/ac33b9df3ddfd21f27eaad5e452d86394ecb7384/app/models/product.rb#L52).  This is used in CustomersDot [in various places for various reasons](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3556#note_690684649).

This issue in particular focuses on removing the usage of `created_at` in [the `Subscription#trueup_products` method](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/eadc95bbcf3256171bd5da0dfe521aa92465b086/app/models/subscription.rb#L210).

### Proposal

It was determined in [this thread](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3556#note_691640374) that a sufficient replacement for `created_at` would be to use the `effective_start_date` of the Rate Plan Charge on the Product.

### Result

A few less dependencies on `Product#created_at` which allows us to eventually remove amendment as a dependency altogether.

Story points: 1.0
Improve maintenance mode coverage

## Problem

As we've been preparing for an upcoming planned Zuora outage in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3538, we performed some testing of our own [maintenance mode feature flag](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/48/edit), `:zuora_application_down`.  We want to turn this feature on to show the maintenance page throughout the duration of the planned outage because without Zuora, CustomersDot will not function properly.

During testing of the maintenance mode, it was discovered that when the feature is enabled, the maintenance page/message is only covered for [the `VisitorsController`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/d671030532e737bbb15669861d259f01c2a48875/app/controllers/visitors_controller.rb#L5).  However, if users are already logged into CustomersDot, they will not see the maintenance mode.  For instance, if they are on the subscriptions page or making a purchase, no message will be shown.

## Proposal

Show the maintenance mode message across more of the application, especially when logged in.  

We could also improve the look of the maintenance mode message, but this would just be a nice-to-have. :smile:

Story points: 1.0
Update docs for CustomersDot plans page

### Documentation

We will need to update all references to the CustomersDot plans page in the docs.

Is there a way to search the docs for all instances of links to `customers.gitlab.com/plans`? I found a couple and listed them below, but I am sure there are more.

#### Should be updated with how to purchase CI Minutes
* ✔️ [Purchase additional CI minutes](https://docs.gitlab.com/ee/subscriptions/gitlab_com/#purchase-additional-ci-minutes) - ~~will be updated with https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68359~~ updated with https://gitlab.com/gitlab-org/gitlab/-/merge_requests/74115 to decouple from CI Minutes release
* [Handling CI minutes](https://about.gitlab.com/handbook/support/license-and-renewals/workflows/saas/ci_minutes.html) - no link detected
* ✔️ [Pricing FAQ](https://about.gitlab.com/pricing/faq/)
* ✔️ [Shared runners blog post](https://about.gitlab.com/blog/2020/01/21/windows-shared-runner-beta/)
* ✔️ [Customer FAQ CI/CD](https://about.gitlab.com/pricing/faq-consumption-cicd/)

#### This is linked by mistake, should be admin
✔️ https://about.gitlab.com/handbook/sales/commercial/smb/#tools

#### Should be safe exchange https://customers.gitlab.com/plans with https://customers.gitlab.com
* ✔️ [Get Started](https://about.gitlab.com/get-started/)
* ✔️ [Marketing Bizible](https://about.gitlab.com/handbook/marketing/marketing-operations/bizible/#bizible-channel-and-sub-channel-mapping)
* ✔️ [Data sources for data team](https://about.gitlab.com/handbook/business-technology/data-team/platform/#data-sources)

Story points: 2.0
Create empty state for "Manage Subscriptions"

Create a component for empty state "Manage subscriptions" page

* For "Manage subscription" page conditionally show empty state component or subscriptions list, see [subscription_list.vue](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/a7bee5cb82383a5af196385ed75fb110d9651229/app/frontend/javascripts/subscription/components/subscription_list.vue#L30-32)
* Update link on the "Buy new subscription" button

All changes should be behind Feature Flag

Story points: 2.0
Clean up /plans code

After rolling out FF `redirect_plans_page`, we need to do a following clean up

- Find usages of plans url in CustomersDot code and replace it with https://about.gitlab.com/pricing/ (for example [subscription_buttons.vue](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/fbb6cb8a0dc1e6e417078585262737a4ddb74b1e/app/frontend/javascripts/subscription/components/subscription_buttons.vue#L241), or root / for [community_program_controller.rb](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/85de06517abbf06e2e53fc73594bb0136bcff1d5/app/controllers/subscriptions/community_program_controller.rb#20), update diagrams, docs, deploy [const](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/fae5f8fbe9435a15e981fbbb3dc605239c467236/bin/deploy) 
- Find usages of plans url in GitLab code and replace it with https://about.gitlab.com/pricing/ for [_promote_issue_weights.html.haml](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/app/views/shared/promotions/_promote_issue_weights.html.haml#L27). Replace it with https://customer.gitlab.com/ for [subscription_portal.rb](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/subscription_portal.rb#L37) and [docs](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/subscriptions/gitlab_com/index.md#L359)
- There might be more, please check during implementation
- Remove obsolete views [index.html.haml](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/0c56a7b766ad4805a3025a0bd436f5dbcb0318d6/app/views/plans/index.html.haml) and [_addon_card.html.haml](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/1e344ed954437a1cad3f78594ab1ed9de5ddfcf9/app/views/plans/_addon_card.html.haml)

Story points: 2.0
SubscriptionTermStartWorker should only process Active subscriptions

## Problem

I noticed when working on #2565, [this specific error in Sentry](https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/2449665/events/3f4c992fc07d45d8a234f4ca3938182a/) where the `SubscriptionTermStartWorker` is processing a callout and does not find the Subscription in Zuora leading to the error.  This error is due to 2 things:

1. The Subscription from the callout was already cancelled so it is not found in the Zuora query because we only find Active Subscriptions [here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/8cd4b49bb71c00887b5c3dd99bd07b339743d186/app/workers/zuora_callout/base_worker.rb#L32).
1. The SubscriptionTermStart callout must be defined incorrectly in Zuora production.  I noticed the `subscription_id` actually contains a leading space in the XML body which you can see in the Sentry error (see below).  This causes [the fallback query here](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/8cd4b49bb71c00887b5c3dd99bd07b339743d186/app/workers/zuora_callout/base_worker.rb#L33) not to find the subscription either.

    ```
    <parameter name=" subscription_id">2c92a00e7bde360b017be47e5a335732</parameter>
    ```  
## Proposal

The `SubscriptionTermStartWorker` can be adjusted to only process subscriptions with a status of "Active".  This should solve item 1 from above.

For item 2, I will reach out to someone in ~"Enterprise Applications" to assist in updating the callout definition.

Story points: 1.0
CDot Subscription Owner Association/Creation for Amendment and Renewal

<!-- Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. 

For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks.

https://www.learning-styles-online.com/style/visual-spatial/

-->

### Problem
In the sales process, salespeople are required to provide information on a Quote about the CDot User that is managing the particular purchase.  For sales-engaged new biz, the contact that is ultimately passed to Zuora as the Zuora Sold To associated with the Zuora Account and Subscription is used to create or associate a CDot User with a Zuora Account/Subscription.  For Amendment and Renewal sales-engaged deals, no User management takes place in CDot to associate any new contacts with a namespace.  This causes provisioning lags that impact revenue recognition because license emails may not be sent to the appropriate use (that is not represented in CDot or not associated with a namespace/Zuora Subscription).

### Proposal
https://gitlab.com/gitlab-com/business-technology/enterprise-apps/intake/-/issues/319#note_676389738

Update [the `FindOrCreateCustomersService`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/a370c2b4b1a4fec50a6be2291c7b0ec7c73e0cd7/app/services/find_or_create_customer_service.rb#L34) to only find Customers using email address.  This means avoid the fallback find logic using `zuora_account_id`.  If new sold to contact information is received in a callout and the email address does not exist, CDot should create a new customer and associate it to the order and account.

### Result
All sales-engaged deals have Zuora Sold-To contact created and/or associated with a Zuora Subscription/Account/Namespace.

### Next steps (if any)
Fulfillment (@tgolubeva) and EntApps (@mquitevis) have already brainstormed a high-level solution.  Next steps are Fulfillment prioritization and working on a detailed solution.

### How will we measure success?
The Zuora Sold To Contact received licensing emails for all deal types (New business, Amendments, Renewals)

### Communication Plan
- [x] When problem/solution validation begins, re-engage cross-functional team members: Mark, Jessica, Sarah, Jesse and Tatyana.
- [~] If and when user design work is deemed necessary and design work starts, communicate the beginning of this development phase.
- [x] When development work begins, communicate status.

Story points: 2.0
Community Programs - update the login/register flow to reflect UX design

### Problem

Related to this bug discovered during testing https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/311#note_677677051

When going through the Community Program signup flow, a customer is asked to register/login first, then select the plan type (SaaS or Self-Manage). If they select SaaS, they are dropped into the checkout page without a way to create a group.  This video shows the current experience https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/311#note_678467160

The original design asked for a different flow.

The SaaS or SM selection should be prior to sign in, and [here's the reasoning](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2677/designs/User_flow.png#note_531957098). A SaaS customer should never see the option to Sign in or Register, only the `Continue with Gitlab.com account` button. If we don't do it this way and the SaaS customer registers a new CustomersDot account, it won't be connected to their GitLab.com account and they won't be able to complete the flow. 


### Proposal

Update the flow to reflect the UX design.

* exclude the landing page from requiring a user login
* when accessing the claim page:
  * if no login: redirect to either register page (for self-managed) or to log in with GitLab page (for SaaS) based on `edition` query string variable
  * if the user is logged in, continue the flow to the claim page without any redirect


### Result

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Group address fields together on the Customer info page

## Problem

When looking at the customer info page (i.e. https://customers.gitlab.com/admin/customer/xxxx), it is difficult to see the full address, as the address fields are randomly ordered on the page.

## Proposal

Move `Address 1` and `Address 2` fields to be near `Country`, `State`, `City` and `Zip code`.

Story points: 2.0
[Engineering]: Pitch a paid plan when users click to purchase CI minutes

# Experiment summary
We believe we can increase paid conversion by informing users of their paid plan options when they go to purchase CI minutes.

# Hypothesis
Users who purchase CI minutes may not know that CI minutes are included with a paid plan. A paid plan may be a better fit for users who are so engaged as to use all of the free minutes allocated to them.

Currently, the experience gives users no information around the free CI minutes included in the paid plans.
| Current Purchase Page | 
| ------ | 
| ![Screen_Shot_2021-09-13_at_3.12.42_PM](/uploads/183308a897b9e059b0e32d48a34c9688/Screen_Shot_2021-09-13_at_3.12.42_PM.png) |

# Business problem
At times, the features of our paid plans are not easily found when initially/casually using the platform.

# Proposed Solution

Inform users of the paid plan options on the purchase page.
- For all free users, we present them with information in the form of a banner about upgrading to GitLab Premium. We then link them to the new subscription purchase flow.
- For premium users who are subscription owners, we present them with information in the form of a banner about upgrading to GitLab Ultimate. We then link them to the CustomersDot Upgrade flow.

| What GitLab Free Users See: | What GitLab Premium Subscription Owners See: |
| ------ | ------ |
| ![Screen_Shot_2021-09-23_at_1.30.55_PM](/uploads/a742da2e783c3427326fae152bb8d035/Screen_Shot_2021-09-23_at_1.30.55_PM.png) | ![Screen_Shot_2021-09-23_at_1.31.06_PM](/uploads/6c48448e806ae7be3afec17ad7ddbb47/Screen_Shot_2021-09-23_at_1.31.06_PM.png) |

#### [Design File](https://www.figma.com/file/ND2SnuptLEBZRtLx5QTMXK/UX-Pitch-a-paid-plan-when-users-click-to-purchase-CI-minutes?node-id=3%3A22)

Story points: 2.0