giseldo/neodataset huggingface dataset:
[Daily Pipeline Fails 4 of 4] Enable daily pipeline run with empty VCR cassettes again

<!-- 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

The [daily pipeline run with empty VCR cassettes](https://gitlab.com/gitlab-org/customers-gitlab-com/-/pipeline_schedules/118484/edit) has been disabled for over a year now. The pipeline didn't pass back then since a lot of new specs were added that use VCR cassettes but there wasn't a rerecordability for all of them.

### Proposal

After all other issues from [the epic](https://gitlab.com/groups/gitlab-org/-/epics/6519) are closed, enable the daily pipeline run with empty VCR cassettes again.

### Result

The daily pipeline run with empty VCR cassettes

### Next steps (if any)

### How will we measure success?

Story points: 1.0
[Daily Pipeline Fails 3 of 4] Evaluate LicenseDot instance usage for daily pipeline run with empty VCR cassettes

<!-- 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

Similar to https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3438, we may require an instance for LicenseDot to use for the daily pipeline run with empty VCR cassettes.

**Note:** It might make sense to tackle https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3551 before this issue since it won't be necessary to have a LicenseDot instance anymore then.

### Proposal

- Evaluate if it's sufficient to reuse LicenseDot staging since LicenseDot is going to be deprecated at some point (if yes, weight: 1)
- If the answer to the above is no, implement something like a temp instance similar to what is being done for a temp GitLab instance in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3438 (weight: 3)

### Result

Clean separation between an instance that is only needed for specs and other envs.

### Next steps (if any)

### How will we measure success?

Story points: 0.0
[Daily Pipeline Fails 2 of 4] Use temp GitLab instance for daily pipeline run with empty VCR cassettes

<!-- 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

There are quite a few requests that are sent to a GitLab instance when running the test suite with empty VCR cassettes. Since the requests are not only get requests, but also put and post ones, we need a own GitLab instance for the daily pipeline run with empty VCR cassettes.

### Proposal

- Check with QA how they spin up a docker instance for the E2E tests (https://gitlab.com/groups/gitlab-org/-/epics/6519#note_643775127)
- Implement the same for the daily pipeline run
- Seed the instance with the test data from [this spec support class](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/3f0cc55d1ef0ee32df77719f5cb5a6743c37b5b3/spec/support/gitlab_seed_service.rb)

### Result

An instance that is only used for specs to write and read data from without polluting other environments like GitLab.com staging.

### Next steps (if any)

### How will we measure success?

Story points: 5.0
Automatically retry failed specs in a pipeline run

<!-- 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

Some specs in the test suite require multiple tries in order to pass. This is going to be a problem for the daily pipeline run with empty VCR cassettes.

### Proposal

Implement retry mechanism into the test suite. Evaluate gems like [rspec-retry](https://github.com/NoRedInk/rspec-retry) that QA is using for E2E tests.

### Result

Making a successful pipeline run with empty VCR cassettes possible by avoiding failures due to random errors like flaky specs, Zuora timeouts or not finding an element.

### Next steps (if any)

### How will we measure success?

Story points: 0.0
Automatically retry failed specs in a pipeline run

<!-- 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

Some specs in the test suite require multiple tries in order to pass. This is going to be a problem for the daily pipeline run with empty VCR cassettes.

### Proposal

Implement retry mechanism into the test suite. Evaluate gems like [rspec-retry](https://github.com/NoRedInk/rspec-retry) that QA is using for E2E tests.

### Result

Making a successful pipeline run with empty VCR cassettes possible by avoiding failures due to random errors like flaky specs, Zuora timeouts or not finding an element.

### Next steps (if any)

### How will we measure success?

Story points: 3.0
[Daily Pipeline Fails 1 of 4] Make all specs rerecordable

<!-- 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

For the daily pipeline run with empty VCR cassettes, we have to make sure that all specs that use VCR are rerecordable.

### Proposal

Find specs that are not rerecordable and fix them.

### Result

All specs being rerecordable.

### Next steps (if any)

### How will we measure success?

Story points: 2.0
Feature Request: add 'download license' to admin section

With license file management moving into CustomerDot admin section now, there doesn't appear to be a way to download the license file, a function that was very useful in LicenseDot.  You can see the license text, but this is not useful for downloading and sending it along; the line breaks get converted into spaces which breaks the license.  Also it's just more convenient having a one-click option for retrieving the license.

There's sort of a workaround by impersonating the user and downloading the file, but this is only applicable to the most recent version of a license, and is error prone ([1](https://gitlab.com/gitlab-org/license-gitlab-com/-/issues/217) [2](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3419) [3](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/2799))

### 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 -->

Frontend and feature tests should accompany this change.

- Frontend tests should ensure that the download license link is present.
- Feature test should ensure that the appropriate MIME is presented, as well as the content within.  (Validate that the downloaded content is the same as the text displayed.)

Story points: 2.0
Cloud License: Investigate reseller purchases getting activation codes

### Summary

[Related slack](https://gitlab.slack.com/archives/C018C623KBJ/p1628090677137200?thread_ts=1628088842.119600&cid=C018C623KBJ)

Reseller purchased licenses should not create and send cloud activation codes.

@teresatison mentioned in slack:

> reseller was out of scope for V1, so no changes there.

But per @amandarueda 

> We should have a look into this because an activation code was generated for this reseller deal.

### Reported examples

1. https://gitlab-federal-support.zendesk.com/agent/tickets/1258 (US team only)
1.
1.

<!---
Please add both severity and priority level according to: https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#severity-labels
--->

Story points: 2.0
Allow edits to super_sonics_aware in Admin interface

### Problem

As discussed in [this Slack thread](https://gitlab.slack.com/archives/CNA13RPPA/p1627925913041500?thread_ts=1627924518.040700&cid=CNA13RPPA), there might be times when Admins would need to edit the `super_sonics_aware` flag for `CloudActivation` records.  This currently isn't possible in the Admin interface.

### Proposal

Allow the `super_sonics_aware` field to be editable from the Admin interface.  We should probably document when this feature should be used.  For example, a customer must legally accept new terms of service before using cloud licensing so this should be known before enabling `super_sonics_aware` for a subscription.

### 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 -->

With the possibility of the "accepting new terms of service", this would call for a new end-to-end test to be created to test this flow.  A [test case](https://gitlab.com/gitlab-org/customers-gitlab-com/-/quality/test_cases) should be created and a test should be written.

Story points: 2.0
CloudActivation should match on subscription_name only

### Problem

We realized in a few cases distinct customer records in CustomersDot can share the same `zuora_account_id`.  Cloud Activations have attributes for `subscription_name` and `customer_id`.  Both attributes are currently used when finding a cloud activation for a subscription ([code](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/748cbc04aee7725b5d6d9544f64768bcf5756768/app/models/subscription.rb#L420)), despite the fact that the subscription could be shared by multiple customer accounts.  This leads to a problem where a customer that has access to a subscription but wasn't the creator of the subscription does not see the activation code in the subscription card in CustomersDot.

![Screen_Shot_2021-08-04_at_9.16.50_AM](/uploads/8957e12288942df79de6dc3d6b47a7f6/Screen_Shot_2021-08-04_at_9.16.50_AM.png)

See [this Slack thread](https://gitlab.slack.com/archives/CNA13RPPA/p1628085874075700) for more details.

### Proposal

Update the [code for finding a cloud activation](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/748cbc04aee7725b5d6d9544f64768bcf5756768/app/models/subscription.rb#L420) for a subscription to only look up by `subscription_name`.  Find any other cloud activation code that involves `customer_id` and consider whether it should be adjusted.

Story points: 2.0
Multi Year Subscriptions and License file start/end dates

### Summary

Self-managed subscriptions sold with a validity period greater than 12 months result in a license file always being generated for the original start date and original end date.  This includes any amendments made to the subscription, such as adding users, often resulting in the system generating a license file with a 12-month validity period in the past.


### Steps to reproduce

1. Have a multi-year subscription
1. Create any amendment to it that would result in a new license being generated, like adding seats to the license, during year 2 or 3.

### What is the current *bug* behavior?

License files created with outdated validity periods. 

**Reason:**
* We generate a legacy license with `term_start_date` + 1 year based on our logic of generating all legacy licenses for 1 year.
* The problem with this is that `term_start_date` matches the original subscription start date - so when we are year 2 or 3 of a MY subscription and a new license is generated, it will be for the first year only.

### What is the expected *correct* behavior?
Generate a license file that matches the relevant, current year of the subscription.


### Workarounds

Generate license manually with the correct dates.

### Reported examples

1. https://license.gitlab.com/licenses/180420
   - Issued at 2021-06-22 ; Starts at 2018-09-28, the original date of the [first amendment on the subscription](https://www.zuora.com/apps/Subscription.do?method=view&id=2c92a00766206962016630c57a8f4072)
1. gitlab-com/support/internal-requests#8536
1. https://gitlab.zendesk.com/agent/tickets/223424
   - [added users to a multi-year](https://www.zuora.com/apps/Amendment.do?method=viewInfo&id=2c92a0fe7a8544b7017a87139ba95503), resulting [license file](https://license.gitlab.com/licenses/182744) Issued at 2021-07-08 ; Starts at 2020-05-22
1. https://gitlab.com/gitlab-com/support/internal-requests/-/issues/8911
   - https://customers.gitlab.com/admin/license/1000675, Issue at 2021-08-12, Starts at 2020-09-30
   - After clicking the download license file in the subscription, a new license was generated: https://customers.gitlab.com/admin/license/1001375, issue at 2021-08-25, Starts at 2020-09-30 

## Proposal
Dynamically calculate the license `end date` and license `start date` for a multi-year subscription on a legacy or offline license based on the provision date.
* By dynamically setting `end date` of the license based on the provision date, we ensure the license is aligned to the current term.
* By dynamically setting `start date` based on provision date, the 1-year increment logic can hold true, allowing true-ups to be calculated correctly. 

Note: an alternative option is to generate all legacy licenses for the full subscription term (i.e. 3 years) but this is not something we are prepared to move to at this time ([comment for details](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3421#note_1230790958)).

Story points: 3.0
PG::StringDataRightTruncation error occurring on activation

https://sentry.gitlab.net/gitlab/customersgitlabcom/issues/2747467/?referrer=gitlab_plugin

```
Stacktrace (most recent call first):

  lib/gitlab/logger_helpers.rb:24:in `public_send'
    Gitlab::Logger.public_send(log_level, object, options) # rubocop:disable GitlabSecurity/PublicSend
  lib/gitlab/logger_helpers.rb:24:in `log'
    Gitlab::Logger.public_send(log_level, object, options) # rubocop:disable GitlabSecurity/PublicSend
  lib/gitlab/logger_helpers.rb:13:in `log_error'
    log(:error, error, extra: extra)
  app/services/cloud_activations/activate_service.rb:132:in `handle_error'
    log_error(message, extra: extra)
  app/services/cloud_activations/activate_service.rb:36:in `rescue in execute'
    handle_error(e.message)
  app/services/cloud_activations/activate_service.rb:21:in `execute'
    def execute
  app/graphql/mutations/cloud_activations/activate.rb:23:in `resolve'
    ).execute
  app/controllers/graphql_controller.rb:21:in `execute'
    result = PaymentAppSchema.execute(query, variables: variables, context: context, operation_name: operation_name)
  lib/middleware/health_check/health_check_responder.rb:14:in `call'
    return @app.call(env) if format.nil? || (ip_blocked(env) && not_authenticated(env))
...
(135 additional frame(s) were not displayed)

PG::StringDataRightTruncation: ERROR:  value too long for type character varying(32)

```

Story points: 1.0
Follow-up from "Add super sonics aware on cloud activations list"

## Proposal

In !3625 we added "super sonics aware" column to cloud activation list as follows:

![](https://gitlab.com/gitlab-org/customers-gitlab-com/uploads/f44be93d329f0f0a238a9021a4192d77/Screen_Shot_2021-07-30_at_10.59.06_AM.png)

During the review a [discussion](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/3625#note_639917181) came up about the output of that column if it is suitable from a UX perspective (it will output either `true` or ` false`), an argument that it's okay is that only admins will see that table.

Should we change this value to something else, or it's okay to keep as is?

Story points: 0.0
Some Admins do not have the expected access levels after Okta sign in

### Problem

There are multiple reports of Admins, mostly Support team members, that do not have the expected read/write access to the Customers Admin interface.  It seems that after signing in via Okta, the Admin record is updated with the read only access level to Customers information. 

Please see this [Slack thread](https://gitlab.slack.com/archives/CK4EQH50E/p1627532249099000) for more details.

#### Background

[Two days ago we enabled the `admin_roles` feature flag](https://gitlab.com/gitlab-org/customers-gitlab-com/-/feature_flags/98/edit) in Production after receiving word that the necessary license app groups have been to the CustomersDot Okta app.  With this enabled, admin roles would be enforced and certain write actions would be restricted based on access levels.  These access levels should be set in [the `Admins::AuthenticateFromOmniauthService`](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/6bbe84277de0cb0c4b6e68dc86afbbe9285c723c/app/services/admins/authenticate_from_omniauth_service.rb#L4) which is executed after Okta redirects back to CustomersDot after successful sign in.   If the customers groups returned from Okta include the CustomersDot write access group (`okta-customerportal-users`), then the read/write access level would be assigned to the Admin.  

However, something seems to be amiss in this integration.  This could be a caching issue where CustomersDot is receiving stale group information.  However, admins have reported attempting to login with multiple browsers, even incognito windows, and still have the issue.

### Proposal

Investigate why this is occurring and fix it.  We need more logging in the authentication service in order to determine what groups CustomersDot is receiving from Okta.  Once we have that information, we should be able to determine if CustomersDot is receiving stale information, pointing to a caching problem, or if there is a bug in the service in CustomersDot.

Story points: 2.0
Upgrade Unleash Gem

We use the Unleash client gem in CustomersDot for our feature flags.

We're currently using version 0.1.6, released September 12th, 2019.  The latest version is 3.2.2, released March 26th, 2021.

Unleash Releases: https://github.com/Unleash/unleash-client-ruby/releases

We should consider upgrading our gem to the latest version.

### 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 -->

As this upgrade is quite significant (major version 0 to major version 3 [three major versions ahead]), we should ensure that all feature flags act as they should.

This may be a mostly manual effort with the help of some feature specs, but we should ensure that the behavior does not change between versions.

Story points: 2.0