giseldo/neodataset huggingface dataset:
Don't show Boosts on my own channel page

<!---
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

Avoid concerns about seeing ads on your own pages by keeping self-owned pages ad-free.

## What needs to be done

- Given I'm the owner of a page that can host Boost Partner Boosts (e.g. channel page, SEP), when I view that page logged-in, then Boosts are not displayed

## 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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
BoostSuggestionInjector - Call to a member function getGuid() on null

<!---
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

Sentry error found

### Steps to reproduce

See Sentry

### Platform information 

Web

### What is the current *bug* behavior?

Error thrown out

### What is the expected *correct* behavior?

Should return null if nothing found or the next boost along - to discuss.

### Relevant logs and/or screenshots

https://minds-inc.sentry.io/issues/3936946297/?query=is%3Aunresolved&referrer=issue-stream

### Possible fixes

Check whether Boost exists

Story points: 1.0
Add Boost end dates to Mautic custom fields

<!---
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
--->

Enable Minds team to build Mautic campaigns that respond to Boosts completing, e.g. to understand how satisfied customers are with their Boost.

## What needs to be done

Add custom fields to Mautic contacts that indicate when their last cash and token Boosts completed.

## 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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
UXD: Create Boost flow from 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

Enable users to create Boosts (channel + activity Boosts) from the Boost console so that more Boosts can be made.

## What needs to be done

Design a flow and UI to be able to create a Boost from the Boost console.

- Channel Boost (can use existing "Boost channel" modal)
- Activity Boost (can use new "Boost latest post" flow?)

## 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=1289%3A23979&t=4NEzNgVJFOP9qobH-1)

![1_Boost_Post_From_Console](/uploads/bea7217870cd4c219e6eff6a35144947/1_Boost_Post_From_Console.png)

![2_Boost_Channel_From_Console](/uploads/c78bc0cfa3725bc485957725eb3eb36f/2_Boost_Channel_From_Console.png)

![Boost_Mobile_Console](/uploads/3a1f44ff66b8e3977ed9deec08dc2fc3/Boost_Mobile_Console.png)

![Boost_Mobile_Console_2](/uploads/dbd8014be3fe9e0d923b6a966fa1a446/Boost_Mobile_Console_2.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: 3.0
Web: Redirect Earn link in navigation to earning blog

<!---
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

Teach Minds community about the various mechanisms by which they can earn on Minds, including the new affiliates program.

## What needs to be done

Change the existing `Earn` link in the site navigation to point to the following blog URL: https://www.minds.com/info/blog/how-to-earn-on-minds-1486070032210333697

![image](/uploads/59b85f68404893b21a97fab89b1dc743/image.png)

## 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
--->

- [ ] Link points to blog (@markryansallee to provide).
- [x] Delete the earn modal

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Web: Add context to previews of paywalled premium content

<!---
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

Increase engagement with PREMIUM content from Minds+ subscribers by making the posts more appealing / engaging to users without Minds+ subscriptions.

## What needs to be done

- Update the presentation of Minds+ paywalled content

## 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.
--->

At a high level, changes fall into three categories:

1. Expose text content for media-based posts
2. Add social proof context to paywalled posts (e.g. Bill follows Jack)
3. Reduce blur of images for image-based posts

#### 1.

[Figma](https://www.figma.com/file/lkwynaYCljUsoeFTqTNJJr/Minds%2B-Paywall?node-id=0%3A1&t=cgizQiiqxEyXdgPW-1)

**Continue Reading Added: Similar use to 'See More' however in this case we use the primary color for the link to serve as a distinguishing factor between the two. Also, when 'Continue reading' is clicked it will open up the Minds+ Modal to subscribe to Minds+ just like the 'Unlock Post' button.**

![1_Continue_reading_added](/uploads/372173ea98f7be2669896d0486b58aa1/1_Continue_reading_added.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.
--->

- Deploy as an experiment and measure for engagement
- Secondary metric: Users clicking "Unlock" button

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Expose the text of images and videos
- [ ] When a paywalled post, see more should now be called 'Continue reading'.
- [ ] When clicking 'Continue reading' it should unlock the post

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Web: Used a dot to indicate new content in Discovery

<!---
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

Increase engagement and new channel discovery by increasing visits to the Discovery tab.

## What needs to be done

- Add a notification dot on the nav icon for Discovery that indicates new content.
- When the user navigates to Discovery, the dot is cleared
- The dot stays cleared for 24 hours

## 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/tHjd7fqgBiiTHRTNq5Ltfp/Web---Composer-and-Sidebar-updates?node-id=223%3A7879&t=89HUIWTvGeOE6Dx0-1) contains animation and hover states

![Dot_Over_Discovery](/uploads/0a9e1ee4f57a31ec8242a7f61ae88c48/Dot_Over_Discovery.png)

**Spec sheet**

![Screen_Shot_2023-03-06_at_4.07.32_PM](/uploads/c59978f877afebbeb22d40d6d4a302e9/Screen_Shot_2023-03-06_at_4.07.32_PM.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.
--->

- Implement as an A-B experiment
- Measure visits to Discovery page


## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Add a notification dot on the nav icon for Discovery that indicates new content.
- [ ] When the user navigates to Discovery, the dot is cleared
- [ ] The dot stays cleared for 24 hours
- [ ] Run as an experiment

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Web: Highlight comments from Minds+ subscribers

<!---
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

Increase reach and engagement for Minds+ subscribers by highlighting their comments in comment threads.

## What needs to be done

Make comments from Minds+ users stand apart from other comments by visually differentiating them.

## 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/QJiT80vS4yOyprLiafWfbM/Comments?node-id=107%3A1973&t=JIBcctypGnhH7h6Y-1)

**Web**

**Specs for Web**

![Screen_Shot_2023-03-06_at_2.32.39_PM](/uploads/a50acb59d9a097005f9697e40d26ee03/Screen_Shot_2023-03-06_at_2.32.39_PM.png)

![Screen_Shot_2023-03-06_at_2.18.20_PM](/uploads/2711503cd4d4f7aa2ab417f7c16ee157/Screen_Shot_2023-03-06_at_2.18.20_PM.png)

**Dark Mode Example**

![Dark_Mode_1](/uploads/8dea5f48943a5314c34e72be10a404f1/Dark_Mode_1.png)

**Light Mode Example Replies Expanded**

![Light_Mode_1](/uploads/b5dabb031dad639a355fbadf205dcfce/Light_Mode_1.png)

**Light Mode Example Comment In Replies**

![Light_Mode_2](/uploads/84944e63f418385652c0bc2ccd6f395d/Light_Mode_2.png)

**Mobile**

**Specs for Mobile**

![Mobile_Specs](/uploads/92c6e083e17e4cf52a80605bc36986ac/Mobile_Specs.png)

![Light_Mode_Mobile](/uploads/21ab2d7ff1c75cebb79125c93a4491d5/Light_Mode_Mobile.png)

**Dark Mode**

![Mobile_Share_Comments](/uploads/c9c47facebeb39779638d4846f91aae5/Mobile_Share_Comments.png)

**Light Mode**

![Light_Mode_Mobile](/uploads/90cc894c62acfea0f9acbd5c1bf4b55f/Light_Mode_Mobile.png)



**Mobile**

## 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
--->

- [ ] A highlight background shows on Minds+ comments
- [ ] Show a Minds+ icon next to the name of the commenter

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Web: Reorganize Boost navigation links

<!---
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

Make links to Boost console accessible and consistent with other patterns on the app / site.

## What needs to be done

Spec placements of Boost links in app / site navigation. Spec where links go to.

## 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/jscTsxloVCRPwAm4LM2E6g/Navigation-Links-Update?node-id=7%3A326&t=FHCMY2tLdWUZwjNV-1)

**Old Design**

![Old](/uploads/2d5f0fe967635f4ba434419a891cc79d/Old.png)

**New Design: Boost button will now open up the boost console similar to the Supermind button**

![New](/uploads/61669a863a2e3ab3610fdbfe9de6f6ec/New.png)

**Have an A/B test to show a profile dropdown with Boost Console swapped for Boost Channel**

![Profile_Dropdown](/uploads/231b6b428ab08d760c68d04e16d5934c/Profile_Dropdown.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
--->

- [x] Swap out the boost links as above
- [x] Run experiment on the Boost Channel / Boost console (top right dropdown).

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Display click counts 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

Show ROI for Boost buyers by reporting on how many link clicks their Boost drove.

## What needs to be done

Add a metrics column/row to display count of link clicks that originated from the Boost.

[A separate issue is adding tracking of those clicks](https://gitlab.com/minds/minds/-/issues/3819).

## 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
--->

- [ ] Add number of clicks column to boost console
- [ ] Presume `total_clicks` will be passed with the summary

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Holding rewards have dash in historic entries as well, not only first page

<!---
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

Holding rewards have dash in historic entries as well, not only first page

### Steps to reproduce

1. Go to your wallet
2. Change a date to previous day
3. See that it still shows same, as on first page

![image](/uploads/8747b38873a086f608f60039c2b9beae/image.png)

### Platform information 

win10, brave

### What is the current *bug* behavior?

The holding rewards show as `-` on previous days

### What is the expected *correct* behavior?

Holding rewards should show that days amounts on previous days

### 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.)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 1.0
No jury ran since october

<!---
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

I've been looking through the jury data, and it appears that no jury ran since october:

![image](/uploads/e0e531677807947effef58b66329cab2/image.png)

### Steps to reproduce

irrelevant

### Platform information 

irrelevant

### What is the current *bug* behavior?

No jury triggered

### What is the expected *correct* behavior?

Jury should be triggered

### 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.)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 3.0
Vitess issues

<!---
Please read this!

A Superhero should only be declared for critical site outages or issues. Please read https://developers.minds.com/docs/handbook/how-we-work/superhero before creating an issue.

Issues created using this template automatically page on call developers.

The Superhero board can be found at https://gitlab.com/groups/minds/-/boards/1388364?&label_name[]=Type%3A%3ASuperhero.
--->

### Is minds.com down?

Vitess is

### What is the issue?

Issues with Vitess

### What username are you logged in with?

Any user

### Console logs

N/A

Story points: 1.0
Update link in the "You got a strike" email

<!---
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

Update link in the "You got a strike" email

### Steps to reproduce

1. Get a strike
2. Open email
3. Inspect the "log in" link

### Platform information 

irrelevant

### What is the current *bug* behavior?

Link links to wrong place

### What is the expected *correct* behavior?

Link should link to the right place

### Relevant logs and/or screenshots

This is how hovering log in looks like:

![image](/uploads/47c986c3b1e46e4e38cc65c3a7699142/image.png)

The link is `https://www.minds.com/settings/reported-content` but it should be `https://www.minds.com/settings/other/reported-content`

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 1.0