giseldo/neodataset huggingface dataset:
minds.com/boost is linking to old boost console

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

<!---
Clearly outline the goal of the issue and why we are doing it
--->
https://minds.com/boost create boost button links to the old boost console. This is awkward because there is no way to boost from new boost console. should link to user's channel. 

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->


## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->


## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->


## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Remove the button

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Migrate homepage(s) to use Angular Image Directive to improve SEO and general performance

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

Improve image load experience, especially LCP time on homepage initially which could potentially have large benefits for SEO - if this is a success, continue to migrate images around the site.

https://www.landsend.com/ migrated in a lab experiment as saw a 75% increase in LCP - we should definitely experiment to see if we get similar results.

## What needs to be done

Implement new [Angular Image directive](https://angular.io/guide/image-directive) on the homepage - **need to discuss whether this is scoped to both variants of the homepage or just the old one for testing purposes**. This directive is new out of developer preview with Angular 15.

Features of note include:

- Intelligent lazy loading based on for example, page visibility
- fetchPriority control 
- Experimental “fill” mode so that it pre-occupies space
- Image loader strategies so that correctly sized images are loaded automatically based on the viewport.

We need to consider what to do with Blurhash and check whether it is compatible, or even needed anymore.

## QA

Test homepage(s?)

## UX/Design

There should be no design changes

## Mobile

- [ ] Is Mobile Required?

## Personas

Initially targeting an improved experience for crawlers while we learn to use the new directive optimally.

## Experiments

N/A - note though the guest mode experiment controls which homepage that you see for testing.

## Acceptance Criteria

- [x] Learn about the directive via [the docs](https://angular.io/guide/image-directive) - figure out best practices and relay information to the team - possibly add to documentation for bonus points.
- [x] Explore whether we are in a position without engine changes where we can implement an [image loader strategy](https://angular.io/guide/image-directive#built-in-loaders) which will request images of the correct sizes for the viewport automatically - if this is too big of a task, break it out into another one.
- [x] Switch the homepages images to use the new image directive, following best practices, and sensible priorities.
- [x] Determine the best strategy for the homepage for preload hints for SSR and implement.
- [x] Determine what to do with Blurhash.
- [x] If it is possible (perhaps through a loader?) have it so that we only have to specify paths to the image in our CDN (are all images through our  CDN?) e.g. `ngSrc="/assets/image.jpg"` rather than currently `[ngSrc]="${this.cdnAssetsUrl}/assets/image.jpg"`.

## Definition of Ready Checklist

- [x] Definition Of Done (DoD)
- [x] Acceptance criteria
- [ ] Weighted
- [x] QA
- [x] UX/Design
- [x] Personas
- [x] Experiments

Story points: 3.0
When hiding a post in the Boost rotator, the Boost rotator appears blank

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

When hiding a post in the Boost rotator, the Boot rotator appears blank.

### Steps to reproduce

- Visit the Newsfeed
- Click the ... menu on a post in the Boost rotator
- Choose to hide the post

### Platform information 

MacOS + Chrome

### What is the current *bug* behavior?

- The Boost is removed / hidden
- The Boost rotator appears blank

### What is the expected *correct* behavior?

- The Boost is removed / hidden
- The Boost rotator advances to display the next available Boost

### Relevant logs and/or screenshots

![image](/uploads/9158e526aa68f48d09723aa635fde863/image.png)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 2.0
Link to Boost content policy with rejection message in Boost console

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

Provide sufficient disclosure / communication about a Boost rejection so that the user is not confused.

## What needs to be done

Add a `Learn more` link to the Boost rejection reason in the Boost console.

Link to here: https://support.minds.com/hc/en-us/articles/11723536774292-Boost-Content-Policy

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

![image](/uploads/8c62d07824fb1e8d9d4a179a6d9cc1f0/image.png)

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [x] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->


## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->


## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [x] Add the link in above
- [x] Learn more to go to zendesk (ryan to add)
- [x] If the rejection reason was invalid audience, Display "Boost again" which would open the boost modal.

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Boost transactions display wrong text in the Wallet

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

Boost transactions in the wallet appear as Boost offers to `@mindsboost`.

### Steps to reproduce

Case 1:
- Create a Boost in V3

Case 2:
- Reject the Boost

### Platform information 

MacOS + Chrome

### What is the current *bug* behavior?

- Transactions appear in the wallet
- The transactions appear as

`Off-Chain Boost Offer to @mindsboost`

`Off-Chain Boost Offer from @mindsboost`

### What is the expected *correct* behavior?

- Transactions appear in the wallet
- The transactions appear as

`Off-Chain Boosted Content`

### Relevant logs and/or screenshots

![image](/uploads/4947216dd68d92d9e0c02d27a7134286/image.png)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 2.0
Add boost settings cog to new boost console

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

<!---
Clearly outline the goal of the issue and why we are doing it
--->
Increase accessibility of boost settings by adding a cog to the boost console

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Add settings cog to boost console

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
Clicking settings cog should lead to user's boost settings page

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->
[Figma designs](https://www.figma.com/file/W2xIag64EdbWUlGAQOpVHE/Boost-Update?node-id=485%3A18241)

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->
Boost consumers

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->
Related to dynamic boosts 

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Settings cog widescreen design implemented
- [ ] Settings cog mobile web design implemented

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Add

Story points: 2.0
Tooltip bug

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

(Summarize the bug encountered concisely)

tooltip scrunched

### Steps to reproduce

(How one can reproduce the issue - this is very important)

sign in. 

### Platform information 

(Browser, device, system stats, screen size)

### What is the current *bug* behavior?

(What actually happens)

### What is the expected *correct* behavior?

(What you should see instead)

### Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's very hard to read otherwise.)

![Screen_Shot_2023-01-27_at_10.09.46_AM](/uploads/530c1b62a04810522cbdd479009cc23e/Screen_Shot_2023-01-27_at_10.09.46_AM.png)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 1.0
Allow admins to toggle between new and old boost queues

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

<!---
Clearly outline the goal of the issue and why we are doing it
--->
Admins need to be able to access the old boost queue and the new one while the `epic-293-dynamic-boost` experiment is enabled. 

Currently when the experiment is enabled, they will only see the new one.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
If we assume the old one will be phased out:

- add a new filter `boosts-v1` to the `minds-admin` component 
- add a tab to that component's html template that points to V1 Boosts
- make it so that tab goes to the old boost console, regardless of experiment active status

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
Admin boost queue access

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->
n/a 

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->
I don't think so?

- [ ] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->
Admins

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->
Relates to `epic-293-dynamic-boost`

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] admins can choose either new or old boost queue while experiment is enabled

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Add link to old Boost console in the new one

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

Enable Boost customers to navigate to the retired legacy Boost console.

## What needs to be done

- Given a customer navigates to the new v3 Boost console,
- and the customer has Boosts in the retired legacy Boost system (v2),
- when the v3 Boost console is displayed,
- then a link to v2 Boost console is presented.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

[Figma](https://www.figma.com/file/W2xIag64EdbWUlGAQOpVHE/Boost-Update?node-id=862%3A19484&t=W4VuvJ1FXi8LTFLu-1)

**Web**

![All](/uploads/a23e77fa237696d1ed0e9e889befc972/All.png)

**Mobile**

![All](/uploads/51628b5e65900f70f56973f6e10f4674/All.png)

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->


## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->


## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Display channel boosts in recommended channels slot

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

<!---
Clearly outline the goal of the issue and why we are doing it
--->
As Minds, I want to add more available channel Boost inventory so that I can better meet the demands of customers.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Update the existing `Recommended Channels` component to include a 4th recommendation that's a Boosted channel.
Designs are provided in https://gitlab.com/minds/minds/-/issues/3666

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->
See https://gitlab.com/minds/minds/-/issues/3666

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [x] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->


## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->
Use the boost v3 epic label

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [x] Boosts show in the recommended channels slots
- [x] Views and correct context are tracked
- [x] For views - look at how the [feed notice analytics](https://gitlab.com/minds/front/-/merge_requests/2155/diffs#45a4bd9f20ad6df6af964f4bfb2012ceac8878de_25_28) are being sent. DM @benhayward.ben if there's any questions

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
Display boosts to channel pages

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

<!---
Clearly outline the goal of the issue and why we are doing it
--->

As a Minds, I want to increase Boost inventory supply so that I can better fulfill the demands of customers.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Add a Boost slot to channel pages.
See https://gitlab.com/minds/minds/-/issues/3281 for mockups

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

Provided in https://gitlab.com/minds/minds/-/issues/3281

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [x] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->

All users

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->

yes, this should use the boost partners epic label `epic-303-boost-partners`


## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Boosts display on channel pages
- [ ] Display in the 2nd slot and then every 6 posts
- [ ] ~~Client meta on view endpoint and snowplow is aware of the channel the boost is being displayed on~~ (no longer required for this ticket @markharding)

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Upgrade to Angular 15

<!---
Please read this!

The Definition of Ready (DoR) can be found at https://developers.minds.com/docs/handbook/how-we-work/#definition-of-ready-dor

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Type::Feature" label and verify the feature you're about to submit isn't a duplicate.
--->

## Goal

<!---
Clearly outline the goal of the issue and why we are doing it
--->

Support Angular 15 so that we do not fall too far behind

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->


## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

Full QA will be required. 

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

N/A

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## Personas

<!---
Who does this user impact and why (optional)
--->
Devs :nerd: 

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->
No

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Angular is upgraded to version 15

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 13.0
Multiple stripe accounts are being created

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

Users are doubling clicking the Connect bank account button, which is sending multiple requests. 

### Steps to reproduce

From a new account, click multiple times on the create cash bank account button. Multiple network requests are made and stripe is creating accounts for each of these requests. 

### Platform information 

Web

### What is the current *bug* behavior?

Multiple accounts are created. There is no lock on the button. 

### What is the expected *correct* behavior?

The button should not process anything whilst 'inProgress'. Only one request should be made. 

### Relevant logs and/or screenshots

N/A

Story points: 1.0