giseldo/neodataset huggingface dataset:
Allow Admins to set Zuora Subscription Super Sonics flags to NULL in the Admin UI

### Problem

Admins are able to check boxes on the Zuora Subscriptions Admin page in CustomersDot which can set a few custom fields in Zuora.  Checking the box sets the field to "Yes".  Later if you uncheck a box, it sets the field to "No".  This was fine when the initial design assumed all these fields would either be "Yes" or "No" but NULL is also a valid state, especially in the dual licensing approach.  

![Screen_Shot_2021-09-16_at_10.36.23_AM](/uploads/c19b85d7aba596cb99f3bd9584af22c4/Screen_Shot_2021-09-16_at_10.36.23_AM.png)

Admins should have the ability set the fields to NULL as well.  It's also unclear if an unchecked box means "No" or NULL.

### Proposal

Update the Zuora Subscriptions Admin page from using checkboxes to dropdowns that contain all three options: "Yes", "No", and NULL.

### Availability & Testing

<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.

What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?

Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change

See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->

Feature specs should be added to accompany this change in addition to any related unit specs.

- Tests that ensure that the various data types (boolean, nil) behave appropriately

Story points: 2.0
Show activation information in the Admin UI

### Problem

Admins are able to view Cloud Activation data in the Admin UI currently, but the information shown is very basic.  The fields include subscription name, activation code, created date, and super sonics aware.

![Screen_Shot_2021-09-15_at_1.45.05_PM](/uploads/ad0ab422252f8721095a91d91b449b56/Screen_Shot_2021-09-15_at_1.45.05_PM.png)

It would be useful for Admins to be able to tell if a customer has activated any instances with a particular code, and when that might have occurred.

### Proposal

For a particular `CloudActivation` record, we should add a link to another page listing all of the `SelfManagedInstanceActivations`.  We would need to join information from the `SelfManagedInstances` table as well

This page could be a simple table with the following columns:

- `self_managed_instances.instance_identifier`
- `self_managed_instance_activations.activated_at`

### Result

An Admin could easily tell if/when instances have been activated with a particular activation code.

### Availability & Testing

<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.

What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?

Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change

See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->

This change would require a new model and associated specs with appropriate associations.  This also applies to the new controller.

Story points: 2.0
[Community Programs Renewal] Add success modal to renewal page

Show modal window if transaction was successful [modal](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/75adc85589a351f9aa523a4ca2f1bd46e7c3d09a/app/frontend/javascripts/purchase/components/purchase_success_modal.vue)

We need two versions of this component: SaaS and SelfManaged

Buttons link to https://gitlab.com/ for SaaS and https://customers.gitlab.com/subscriptions for SelfManaged

| SaaS | SelfManaged |
| ------ | ------ |
| ![Screenshot_2021-09-15_at_18.39.35](/uploads/7ef0cef40c371a66abc6d5590a2d7045/Screenshot_2021-09-15_at_18.39.35.png)| ![Screenshot_2021-09-15_at_18.39.47](/uploads/ed4fe1e3e317c90dccc67282ef5934f6/Screenshot_2021-09-15_at_18.39.47.png)|

Design issue: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2747/

Story points: 2.0
[Community Programs Renewal] Add purchase confirmation to renew page

Add purchase confirmation [component](
https://gitlab.com/gitlab-org/customers-gitlab-com/blob/f86054a4cb83d5536a2f5093830b4b47d7a55ff0/app/frontend/javascripts/purchase/components/purchase_confirmation_card.vue)

![Screenshot_2021-09-15_at_18.35.49](/uploads/db3fab2d140b1dba01402d0d9874b8a0/Screenshot_2021-09-15_at_18.35.49.png)

Design issue: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2747/

Story points: 1.0
[Community Programs Renewal] Add coupon input to renew page

Add [component](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/fa85e92d41afbdd97d324d6a4a37f0cba16529e5/app/frontend/javascripts/subscription/components/coupon_code_input.vue) to the renew page

![Screenshot_2021-09-15_at_18.29.50](/uploads/6cc47e0206b955b0089e98f915393734/Screenshot_2021-09-15_at_18.29.50.png)

Design issue: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2747/

Story points: 2.0
[Community Programs Renewal] Add a renew landing page

* add a new route `/subscriptions/community_program/renew`
* re-use templates that we build for CE subscription `community_subscription_landing_page.vue`

Buttons link to `/subscriptions/community_program/my_renewal`
* add a new route `/subscriptions/community_program/my_renewal`
similar to https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/3dcda9b79ed975fc0b18f5f01941de4d38bff91b/app/controllers/subscriptions_controller.rb#L117

If user has only one subscription -> redirect directly to `/subscriptions/community_program/A-SXXXXX/renew`, if more than one -> to `/subscriptions`

![Screenshot_2021-09-15_at_18.07.09](/uploads/84a0f3e7cdb5624b0540f4c69a083798/Screenshot_2021-09-15_at_18.07.09.png)

Design issue: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2747/

Story points: 3.0
Add name field to GraphQL Subscription Type

<!-- 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

Systems other than CDot might need to be aware of a Subscription name.

### Proposal

It would be useful on some occasions (such as the one born from this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/338546#note_674033407)) to retrieve the name of a Subscription.

This is [how it can be done](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3720#note_674681374).

Story points: 1.0
CloudActivation returning empty subscription instead of nil

https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/2801577

Some cloud activation were triggered but the current subscription cannot be found.

## `A-S00019212`

There are no current or future versions. The last one ended in Sat, 12 Sep 2021.

Activation code was created in Thu, 09 Sep 2021 22:21:04.

We will need to investigate why activation code was created for this customer who does not have a subscription.

Story points: 1.0
Zuora iFrame is not always aware of the current customer

<!-- 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

When used in different a context than CDot, the Zuora iframe does not seem to always be aware of who's the current customer. This leads to the rejection of some actions to amend existing subscriptions (for more details, [here](https://gitlab.com/gitlab-org/gitlab/-/issues/338546#note_674033407)).

### Proposal

Use the already implemented `user_id` to retrieve the customer that has sent the request and its Zuora account.

Story points: 1.0
[Community Programs Renewal] Add customer information to the renew page

Add customer information [component](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/76db4040e6294daa2da5ae813f667c54d34781a5/app/frontend/javascripts/subscription/components/customer_information.vue)

![Screenshot_2021-09-09_at_17.06.58_copy](/uploads/8b319c4312394cfee1f36791225561a5/Screenshot_2021-09-09_at_17.06.58_copy.png)

Design issue: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2747/

Story points: 1.0
[Community Programs Renewal] Add description to renew page

Add description component to Community Program renew page

We need two versions of this component: SaaS and SelfManaged

* for SelfManaged version add a collapsible element with a hint text from [subscription_renew.vue](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/a8d38ed9bd91be182e6288ff341a0c736713788f/app/frontend/javascripts/subscription/components/subscription_renew.vue#L337). We already have this element glued in the `subscripton_renew` component so it is a good time to extract it and use in two places

| SaaS | SelfManaged |
| ------ | ------ |
| ![Screenshot_2021-09-09_at_15.36.57](/uploads/4577a476190ea4407650bbd330d39b26/Screenshot_2021-09-09_at_15.36.57.png) | ![Screenshot_2021-09-09_at_15.37.28](/uploads/7d8437a9e0773765a20d911556004062/Screenshot_2021-09-09_at_15.37.28.png) |

Design issue: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2747/

Story points: 3.0
[Community Programs Renewal] Add a renew page

* Add a new route `/subscriptions/community_program/A-SXXXXXX/renew`
* Add basic titles to the page 

![Screenshot_2021-09-09_at_14.55.48](/uploads/c484be56dcf75482e446973c2a04f694/Screenshot_2021-09-09_at_14.55.48.png)

Design issue: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2747/

Story points: 3.0
[Community Programs Renewal] Enable renew buttons for subscription card

Show "renew" buttons on `/subscriptions` page for Community Program card

Link for the button should lead to `/subscriptions/community_program/A-SXXXXXX/renew`

Button should only show up when `community_program_renewals` feature flag is turned on (and when its up for renewal)
 
[Community Program Subscription Renewal Setup instructions](https://gitlab.com/groups/gitlab-org/-/epics/5711#steps-to-setup)

Story points: 2.0
[Community Programs Renewal] Add renewal info banner

Add a renewal info banner to Community Program card on `/subscriptions` page. The banner should show up 3 months before the expiration.

[Related implementation conversation](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3575#note_886396335)

Banner should only show up when `community_program_renewals` FF is turned on.

[Edge case] If customer has more than one community program subscription under an account, we should display an alert for each community program subscription subscription that is up for renewal with `Renew` CTA in a list at the top

`application` leads to:

* GitLab for Education link: https://about.gitlab.com/solutions/education/join/#application
* GitLab for Open Source link: https://about.gitlab.com/solutions/open-source/join/#application
* GitLab for Start-ups is not relevant, because that program is only a single-year subscription (no renewals)



![Screenshot_2021-09-09_at_14.28.23](/uploads/4fdf553f6c3d548f11e4f34d79cf6ead/Screenshot_2021-09-09_at_14.28.23.png)

Design issue: https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2747/

[Community Program Subscription Renewal Setup instructions](https://gitlab.com/groups/gitlab-org/-/epics/5711#steps-to-setup)

Story points: 2.0
Do not repeat quote_invoice if quoted_invoice_amount is present

The following discussion from !3751 should be addressed:

- [ ] @shreyasagarwal started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3751#note_673204753): 

    > @qzhaogitlab Thank you for the call and clearing my doubts. Do you think we can call to quote the invoice only once and not call if the `quoted_invoice_amount` is already filled ?

If after quote_invoice succeed, the `email_notification` failed, the job will retry. During the retry, it will `quote_invoice` again. In this case, we do not need to repeat the quote_invoice.

Story points: 1.0
Modify the subscription_update endpoint to support an Order Processed callout

### Background

As discussed in https://gitlab.com/gitlab-com/business-technology/enterprise-apps/intake/-/issues/322#note_666782612, Order action callouts are triggered for each order action (add product, remove product, etc) added to a processed order.  This is similar to amendment callouts, however there is one big difference.  With Amendments, each Amendment processed yields a new version of the subscription.  This isn't necessarily the case with Order Actions.

When processing Amendment callouts in CustomersDot, CustomersDot will only consider a callout if the subscription status is Active in order to avoid provisioning a subscription multiple times.  For instance, if a subscription was upgraded from premium to ultimate, a `RemoveProduct` amendment and `NewProduct` Amendment would be created but only the last Amendment (e.g. NewProduct) would have an "Active" subscription status, as that is the latest subscription.

If we use Order Action callouts, we would need a way to determine the last callout to process and skip the others.  Otherwise, CustomersDot would provision a subscription multiple times.  

### Proposal

Instead of configuring Order Action processed callouts, we should use Order processed callouts.  This would yield only one callout, no matter how many Order Actions were processed, eliminating the step of determining which callout to process.

We'd have to make some adjustments in callout processing code where `amendment_type` is currently referenced.  Callout params would not contain this parameter.  This would have to be queried from the Order Actions types associated with the Order in Zuora.

FYI, it doesn't look like Orders are supported by IronBank, the gem used in CustomersDot.  This will be added as part of https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3568.

Story points: 5.0
Update IronBank to support Orders

### Background

As part of updating CustomersDot to work with the Orders Harmonization feature in Zuora, CustomersDot needs to be able to query Orders and Orders Actions.  This will be helpful in processing "Order Processed" callouts sent by Zuora for Order related transactions.

It does not appear that [IronBank](https://github.com/zendesk/iron_bank), the gem used by CustomersDot to interact with Zuora, supports Order related resources.

### Proposal

Let's investigate whether we can update the IronBank gem to add resources for `Order` and `OrderAction`.  We could also submit a merge request to the IronBank project to contribute to the open source project.

[Here's the Orders object model](https://knowledgecenter.zuora.com/Billing/Subscriptions/Orders/BA_Orders_Object_Model) from the Zuora docs for reference.

Story points: 3.0
Follow-up from "Introduce a flag to stop reconciliations"

The following discussion from !3812 should be addressed:

- [ ] @rpereira2 started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3812#note_671518810): 

    > **suggestion (non-blocking)**: We can add a spec showing that it returns `eligible_for_reconciliation: false` if the feature flag is off.

Story points: 1.0
Follow-up from "Remove storage_plan Feature Flag"

The following discussion from !3784 should be addressed:

- [ ] @vshumilo started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3784#note_669109888):  (+1 comment)

    > **suggestion (non-blocking):** Looks like there is an opportunity here for further clean up - follow up.
    > 
    > I think one easy win will be to remove these `enabled:` key/values + get rid of `enabled_add_ons` and start using `add_ons` directly.

### Acceptance Criteria

Consolidate the `PlansHelper`: `enabled_add_ons` and `add_ons` methods by removing the `enabled` attribute now that is `true` for all cases. Depending on the approach, update the [usage](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/2373988852a2bd1e3441fc63a11c37bc58161f53/app/views/plans/index.html.haml#L54) of the `enabled_add_ons` with the final method name.

Story points: 1.0
Unlink subscription job sends email for existing namespaces

### Problem
I noticed a few emails to unlink a .com subscription locally that didn't seem right. They were sent despite of the namespace existing on my local GitLab instance. The reason for this was that my local GitLab instance wasn't ready to run yet and returned a 502 error.

### Proposal
Modify [UnlinkedComSubscriptionNotificationJob](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/d72d861f03fcfe394b0320d48f9ae23bc55d3372/app/jobs/unlinked_com_subscription_notification_job.rb) to not try to unlink a subscription if the error code of the GitLab request returns a 50x error. Alternatively, only execute the logic to unlink when the error code is 404.

### Result
Not sending emails for existing namespaces when the GitLab request results in a 50x error.

Story points: 1.0
Add unit tests for ChangeNamespaceOverageSummary

<!-- 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

After the changes from https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/7244, the component has a link to a specific page.

### Proposal

<!-- Consult with `@gitlab-com/business-technology/enterprise-apps/zuora-architects` on the ~"Enterprise Applications" team if Zuora business logic is involved. -->

To make the component more resilient to future changes, let's add some unit tests.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Add `Zuora Subscriptions` readonly Admin action

### Problem

Some readonly admins often require / might benefit from having access to a readonly version of the Zuora Subscriptions action (Zuora Subscriptions tab when you click on a customer or billing account.).

Recently as part of a compliance update we removed the access to this tab for 400+ team members because these team members were moved to readonly and this actions is currently only available for Admin managers.

[More optional context here - External](https://gitlab.slack.com/archives/CMJ8JR0RH/p1682680293916259)

### Proposal

- Update the `zuora_subscriptions` action so it is possible to render its associated view as readonly
- Allow the `zuora_subscriptions` action for readonly Admins

### Approval for merging

@mgass1 Would you please :white_check_mark: this issue for approval? (A reaction to this comment should be enough)

I have referenced the [external conversation](https://gitlab.slack.com/archives/CMJ8JR0RH/p1682680293916259) for the MR reviewers reference but given this is a roles related change, want to make sure there is a formal "this is OK to to ship from the product perspective" for the maintainer merging this.

Story points: 2.0
Change sold to/bill to contact wording to subscription/billing contact

<!-- 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

Follow up from comment https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/5890#note_1337326253

> `Bill to` and `Sold to` are rather technical terms that I'm not sure we should be exposing to the customer. Additionally, we don't give the user any information about what the difference is between bill to / sold to.

### Proposal

consider calling them `Subscription contact` and `Billing contact` and adding some information text below the header for each.

Something like:

### Subscription contact

This individual is the primary contact for the subscription and receives notifications and instructions on applying the subscription and keeping it up to date.

### Billing contact

This individual is the primary contact for billing and receives the invoices for all purchases.

### Result

### Next steps (if any)

### How will we measure success?

Story points: 1.0
Follow-up from "Use namespace from the params"

The following discussion from !7180 should be addressed:

- [x] @rkumar555 started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/7180#note_1372229961): 

    > **Suggestion(:non_blocking)** I think it is better to sort this array alphabetically.

- [x] @rkumar555 started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/7180#note_1372236921): 

    > **Suggestion(:non_blocking):** I think it is more cleaner. WDYT?

```suggestion
        let(:namespace_attrs) { namespace.with_indifferent_access }namespace.w_i_a
```

- [x] @rkumar555 started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/7180#note_1372243287): 

    > **Suggestion(:non_blocking):** WDYT to write like this? I don't have this project setup so I can not test and be sure if this works.

- [x] @rkumar555 started a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/7180#note_1372248115): 

    > **Suggestion(:non_blocking):** How do you think to write like this if this works?

```ruby
expect(customer.orders.last).to be_trial
```

Story points: 1.0