giseldo/neodataset huggingface dataset:
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/2b66d71c00cd78b3d32f4ec02f40ced9/All.png)

**Mobile**

![All](/uploads/52add889ef73fa57872855bf99d82eb1/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
Boost text updates

<!---
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
--->

Simplify bottom bar text on boost.


## 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.
--->

[Figma](https://www.figma.com/file/W2xIag64EdbWUlGAQOpVHE/Boost-Update?node-id=863%3A19887&t=W4VuvJ1FXi8LTFLu-1)

**Web**

![U_dated_Boost_Post_Mobile_-_Cash](/uploads/fcf1ddf2e69a62ccb768da681bdd0656/U_dated_Boost_Post_Mobile_-_Cash.png)

![Updated_Boost_Post_Mobile_-_Tokens](/uploads/fd212146e67d0643fb9696f63c9d3ccf/Updated_Boost_Post_Mobile_-_Tokens.png)

![Updated_Boost_Post_Web_-_Review_Boost_Cash](/uploads/96e6557db2c8466b9f570ee8bd9e7a49/Updated_Boost_Post_Web_-_Review_Boost_Cash.png)

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

![Updated_Boost_Post_Mobile_-_Cash](/uploads/343f4d4090c3f898469dab4cc7274b7e/Updated_Boost_Post_Mobile_-_Cash.png)

![Updated_Boost_Post_Mobile_-_Tokens](/uploads/39ad6f666f0942eea62816a8b6a0f336/Updated_Boost_Post_Mobile_-_Tokens.png)

![Updated_Boost_Post_Mobile_-_Review_Boost_Cash](/uploads/df7b1867aabf5571089d94c81313048b/Updated_Boost_Post_Mobile_-_Review_Boost_Cash.png)

- [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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Update copy on Boost marketing 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

Ensure the [Boost marketing page](https://www.minds.com/boost) copy reflects the way the new Boost system works.

## What needs to be done

Copy changes [are outlined here](https://docs.google.com/document/d/10lJko0_tpvu0Wxwv-AqTmPBRracS0dLdc5fVuhjc8eI/edit#heading=h.yt10gdju391g).

- Update copy for top section, `Expand your reach and gain thousands of views`
- Update copy for the 2nd section, `1 token = 1,000 views`
- Update copy for the 3rd section, `Boost Campaigns`
- Remove the 4th section, `Boost Offers`

## 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
Create an in-feed notice promoting Boost Partners

<!---
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
--->

Clearly communicate to users of Boost Partners through the use of an in-feed notice that prompts them to join Boost Partners.

## What needs to be done

Create an in-feed notice for Boost Partners.

Read more links to: https://www.minds.com/info/blog/introducing-boost-partners-program-1477787849246904328

Settings links to Boost settings.

## 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=846%3A19064&t=6dPYn7qWCP7cjdH8-1)

![In-feed_notice](/uploads/689176cc9fdd7039a6ae5435ad5b29f0/In-feed_notice.png)

![In-feed_notice](/uploads/533bd34db5d75d1e70a5755689362915/In-feed_notice.png)

## 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
Update copy on Monetize modal

<!---
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

- Better communicate the existing content policy on Premium Content
- Communicate that the existing policy will be enforced

## What needs to be done

Update the copy on this modal:

> Submit this post to Minds+ Premium Content and earn a share of our revenue based on how it performs.

> [ ] I agree to the [https://www.minds.com/p/monetization-terms](Minds monetization terms) and have the rights to monetize this content.
> 
> - This content is my original content
> - This content is exclusive to Minds+
> 
> I understand that violation of these requirements may result in losing the ability to publish Premium Content for Minds+ members.

Old:

![image](/uploads/7ea0591cf5b9d5f4807a20c6bfa8e900/image.png)

New:

![image](/uploads/721a1dc1024417a0a917e5b1a8e8c2ff/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?
--->

- [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
--->

- [ ] The text has been changed

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Remove Boost from Admin queue after it's approved or rejected

<!---
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 efficiency for the Admin team inside of the new Boost queue.

## What needs to be done

- Given a Boost appears in the Admin queue,
- when an Admin either approves or rejects the Boost,
- then the Boost is visually removed from the Admin queue

Note that the goal here is Admin efficiency. The faster we can get adjudicated Boosts out of the queue, the faster they can get through it.

With this in mind, worth considering prioritizing removing an item visually quickly, without waiting for network / validation. On the rare occasion that network / validations occurs, it may be preferable to quickly dismiss that item and have it re-appear in the queue (flash), rather than keep the item in the queue for the duration of the network / validation request.

## 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
--->

- [ ] After a boost is actioned, it should be removed from the page.

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Communicate upcoming Boost changes to Boosters

<!---
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

- Inform current Boosters about the upcoming changes to Boost
- And that the switchover may impact the Boost they are about to create

## What needs to be done

Add some messaging to the current Boost modal that communicates that (a) things are changing soon, and that (b) their Boost delivery may different than expected because of it.

Link copy points to: https://www.minds.com/info/blog/bid-farewell-the-boost-backlog-1445548466339057665

Given we will likely have a sizable Boost backlog of v2 Boosts when we're ready to switch to v3, @benhayward.ben proposed migrating v2 Boosts to v3 system. The user impact is that their Boosts will effectively be moved to the bidding system, in which their view numbers are not guaranteed. Customers should be aware of this possibility with their newly-purchased v2 Boosts.

![image](/uploads/c60b4707a7ad4886a987d8031648df10/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.
--->

[Figma](https://www.figma.com/file/W2xIag64EdbWUlGAQOpVHE/Boost-Update?node-id=879%3A20716&t=BaObSlJNAm1veHmY-1)

**Web**

![Boost_Post_Web_-_Cash](/uploads/a40501369813611f8ec0b19a33ece0ba/Boost_Post_Web_-_Cash.png)

![Boost_Post_Web_-_Tokens](/uploads/78a2fdde0b5bf9101ab7028a1fc963e7/Boost_Post_Web_-_Tokens.png)

![Boost_Channel_Web_-_Cash](/uploads/b40848d8e4206b7afb415ad9d68d1218/Boost_Channel_Web_-_Cash.png)

![Boost_Channel_Web_-_Tokens](/uploads/dfd49594f2a9cf8390d2c4d4cf7c2e67/Boost_Channel_Web_-_Tokens.png)

**Mobile**

![Boost_Post_Mobile_-_Cash](/uploads/486d931499fa2e667f7849a890779af1/Boost_Post_Mobile_-_Cash.png)

![Boost_Post_Mobile_-_Tokens](/uploads/2df471cae20d82bd8da76d8215f3a723/Boost_Post_Mobile_-_Tokens.png)

![Boost_Channel_Mobile_-_Cash](/uploads/434ac38b55f30a800152176ae3d9f959/Boost_Channel_Mobile_-_Cash.png)

![Boost_Channel_Mobile_-_Tokens](/uploads/fb82fb28b7a87f9c9178e18a323fc0db/Boost_Channel_Mobile_-_Tokens.png)

## 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
Add Boost-related context to 'action' events and views

<!---
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

- As Minds, I want to know what is the engagement rate of Boosted posts in various positions in the app so that I can optimize the performance of Boosts.
- As a Boost user, I want to know what engagements on my post are attributable to a Boost, so that I can evaluate the ROI for Boosting.

## What needs to be done

Add context to engagement events (upvotes, downvotes, reminds, comments) that enables us to discern these engagements from organic appearances and Boosted appearances.

The 'view' event currently has support for supplying client_meta which includes the campaigns, medium etc. We should extend these to be sent along with actions such as upvotes etc. 

For snowplow we should consider introducing a new `context` that will store the above information. The new context should also be able to provide the context of the feed, such as recommendation slot.

## 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

- [x] Mobile ticket required?

Mobile will need to send the context with the events such as 'votes'.

## 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
--->

- [ ] Action events should include the context of the entity
- [ ] Backend should use the context when emitting out to snowplow
- [ ] Update 'view' events to also use the new context

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
Error: Call to a member function isOwner() on null when trying to read deleted group's review queue

Sentry Issue: [ENGINE-4Y](https://sentry.io/organizations/minds-inc/issues/1195076403/?referrer=gitlab_integration)

```
Error: Call to a member function isOwner() on null
  File "/Controllers/api/v1/groups/review.php", line 22, in Minds\Controllers\api\v1\groups\review::get
    if (!$group->isOwner($user) && !$group->isModerator($user)) {
  File "/Api/Factory.php", line 70, in Minds\Api\Factory::build
    return $handler->$method($pages);
  File "/Controllers/api/api.php", line 76, in Minds\Controllers\api\api::get
    return Factory::build($pages, $this->request, $this->response);
  File "/Core/Router.php", line 138, in Minds\Core\Router::route
    return $handler->$method($pages);
  File "/index.php", line 9
    $router->route();
```

Story points: 1.0
Error: Call to undefined function elgg_normalize_url() when building SEO image tag URL

Sentry Issue: [ENGINE-49](https://sentry.io/organizations/minds-inc/issues/1192152261/?referrer=gitlab_integration)

```
Error: Call to undefined function elgg_normalize_url()
  File "/classes/ElggEntity.php", line 1005, in ElggEntity::getIconURL
    return elgg_normalize_url($url);
  File "/Core/Media/SEO.php", line 80, in Minds\Core\Media\SEO::viewHandler
    'og:image' => $entity->getIconUrl('xlarge'),
  File "[internal]", line 0, in call_user_func_array
  File "/Core/SEO/Manager.php", line 69, in Minds\Core\SEO\Manager::get
    $meta = call_user_func_array(self::$routes[$route], [array_reverse($slugs)]) ?: [];
  File "/var/www/Minds/front/dist/en/index.php", line 2, in include
    $meta = Minds\Core\SEO\Manager::get();
...
(3 additional frame(s) were not displayed)
```

Story points: 2.0
Error: Call to a member function getEmail() on null when reading settings

Sentry Issue: [ENGINE-26](https://sentry.io/organizations/minds-inc/issues/1179022582/?referrer=gitlab_integration)

```
Error: Call to a member function getEmail() on null
  File "/Controllers/api/v2/settings/emails.php", line 41, in Minds\Controllers\Api\v2\settings\emails::get
    'email' => $user->getEmail(),
  File "/Api/Factory.php", line 70, in Minds\Api\Factory::build
    return $handler->$method($pages);
  File "/Controllers/api/api.php", line 76, in Minds\Controllers\api\api::get
    return Factory::build($pages, $this->request, $this->response);
  File "/Core/Router.php", line 138, in Minds\Core\Router::route
    return $handler->$method($pages);
  File "/index.php", line 9
    $router->route();
```

Story points: 2.0
Exception: user_guid be be sent when getting Update Markers

Sentry Issue: [ENGINE-D](https://sentry.io/organizations/minds-inc/issues/1177469648/?referrer=gitlab_integration)

```
Exception: user_guid be be sent
  File "/Core/Notification/UpdateMarkers/Repository.php", line 34, in Minds\Core\Notification\UpdateMarkers\Repository::getList
    throw new \Exception('user_guid be be sent');
  File "/Core/Notification/UpdateMarkers/Manager.php", line 28, in Minds\Core\Notification\UpdateMarkers\Manager::getList
    return $this->repository->getList($opts);
  File "/Core/Groups/Membership.php", line 649, in Minds\Core\Groups\Membership::getGroupsByMember
    'limit' => 1000,
  File "/Controllers/api/v1/groups.php", line 52, in Minds\Controllers\api\v1\groups::get
    'offset' => (int) $_GET['offset'],
  File "/Api/Factory.php", line 70, in Minds\Api\Factory::build
    return $handler->$method($pages);
...
(3 additional frame(s) were not displayed)
```
We need to check to make sure that we check for an authenticated user before we request update markers

Story points: 3.0
(bug): Ensure Contributions\Repository handles faulty $rows values

Sentry Issue: [ENGINE-J](https://sentry.io/organizations/minds-inc/issues/1177479145/?referrer=gitlab_integration)

```
Error: Call to a member function pagingStateToken() on boolean
  File "/Core/Rewards/Contributions/Repository.php", line 124, in Minds\Core\Rewards\Contributions\Repository::getList
    'token' => $rows->pagingStateToken()
  File "/Controllers/api/v2/blockchain/contributions.php", line 36, in Minds\Controllers\api\v2\blockchain\contributions::get
    'offset' => $offset
  File "/Api/Factory.php", line 69, in Minds\Api\Factory::build
    return $handler->$method($pages);
  File "/Controllers/api/api.php", line 76, in Minds\Controllers\api\api::get
    return Factory::build($pages, $this->request, $this->response);
  File "/Core/Router.php", line 137, in Minds\Core\Router::route
    return $handler->$method($pages);
...
(1 additional frame(s) were not displayed)
```

Story points: 2.0
(bug): Wire\Thresholds should handle NULL users (logged-out)

Sentry Issue: [ENGINE-1T](https://sentry.io/organizations/minds-inc/issues/1178004156/?referrer=gitlab_integration)

```
Cassandra\Exception\InvalidArgumentException: num must be a long, double, numeric string or a Cassandra\Varint instance,  given
  File "/Core/Wire/Sums.php", line 114, in Cassandra\Varint::__construct
    new \Cassandra\Varint($this->sender_guid),
  File "/Core/Wire/Sums.php", line 114, in Minds\Core\Wire\Sums::getSent
    new \Cassandra\Varint($this->sender_guid),
  File "/Core/Wire/Thresholds.php", line 63, in Minds\Core\Wire\Thresholds::isAllowed
    $amount = $sums->getSent();
  File "/Core/Media/Thumbnails.php", line 26, in Minds\Core\Media\Thumbnails::get
    if (!Di::_()->get('Wire\Thresholds')->isAllowed($loggedInUser, $entity)) {
  File "/Controllers/fs/v1/thumbnail.php", line 36, in Minds\Controllers\fs\v1\thumbnail::get
    $thumbnail = $mediaThumbnails->get($pages[0], $size);
...
(4 additional frame(s) were not displayed)
```

Story points: 2.0