giseldo/neodataset huggingface dataset:
Provide payment_txid for dynamic boost exports

<!---
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
--->
Provide `boost.payment_txid` to be used in receipt link for users in the boost console. To be used as depicted in mockup below:

![image](/uploads/2bffe4dd8cfe936372bee203b577f2ec/image.png)

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Provide a `payment_txid` for the receipt of dynamic boosts on export, (if a receipt exists).

This field should be usable in the same way that it is used in the supermind console, e.g. alongside the `api/v3/payments/receipt` endpoint, like: 
`[href]="'/api/v3/payments/receipt/' + boost.payment_txid"`

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
- Links are provided when a receipt exists
- Links point to the correct place

## 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 screenshot above

## Personas

<!---
Who does this user impact and why (optional)
--->
Boost 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.
--->
Relates to `epic-293-dynamic-boost`

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] `payment_tx_id` provided in boost export if available
- [ ] Clicking on a cash receipt link to `api/v3/payments/receipt/{boost.payment_tx_id}` should redirect to receipt page
- [ ] Clicking on an onchain boost reciept link should go to `etherscan.io/tx/{boost.payment_tx_id}`

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Get counts of boosts for each target audience type for admin boost queue

<!---
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 should know how many items are in each tab of the boost queue, as pictured in the "safe"/"controversial" row below:


![image](/uploads/fd98ae8283ae011234f63183e9c3471a/image.png)

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Add endpoint that allows clients to request/receive counts of pending boosts in the admin boost queue, grouped by target audience/suitability. The boost queue counts should be accessible by admins only. 

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
Counts are accurate and up-to-date. 
Counts should decrement when the admin takes action on a pending boost (either approves or rejects it).

## 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 screenshot above for proposed functionality for this feature.

## 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
--->

- [x] Admins can get total counts of items in the boost queue, grouped by target audience type
- [x] Implement to frontend admin console as per screenshot above
- [x] New api endpoint for 'api/v3/boost/admin/stats'

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Add completed state to dynamic boosts

<!---
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
--->
Denote whether a boost has been successfully completed -- for use in the boost console.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Add a new boost state `COMPLETED` to the dynamic boost data model, and provide this value on export of boosts. Currently assuming it will be attributed to number `9` in the enum.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
The `boost_status` is in `COMPLETED` state if the boost duration has elapsed since the boost was approved/boosted. 

## 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

## Personas

<!---
Who does this user impact and why (optional)
--->
Boosting 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.
--->
Relates to `epic-293-dynamic-boost`

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] `COMPLETED` boost state is incorporated into boost api
- [ ] Cronjob should mark completed boosts as completed
- [ ] Should also send onComplete ActionEvent via Boost ActionEventDelegate

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
SPIKE: Investigate introducing an automated marketing tool

<!---
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
--->
Non-devs wish to be able to control the marketing plane 

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Investigate possible tools such as:

- Posthog (https://posthog.com/)
- Mautic (https://www.mautic.org/)
- Laudspeaker (https://laudspeaker.com/)

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
N/A

## 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


## Personas

<!---
Who does this user impact and why (optional)
--->
Internal team

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->
N/A

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Prototype of working platform in a sandboxed environment


## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

S

Story points: 8.0
Spike: Explore Estimated Reach logic for boosts

<!---
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 meaningful estimates on boost reach to boosting users

## What needs to be done

Devise a strategy to provide users meaningful estimates on Boost Reach

## QA

No deliverable to QA in the traditional sense - we should peer review the ideas created from this card.

## UX/Design

No UX and design however we may need to make subsequent design changes based on the outcome of this card.

## Personas

Boosting users.

## Experiments

The eventual feature will be under the parent dynamic boost epic flag.

## Acceptance Criteria

- [ ] Create a proposal for a strategy for delivering estimated reach that provides users a meaningful estimate with a reasonable degree of accuracy.
    - Lower bound is especially important - if we do not believe we can do this accurately, we should consider omitting it.
    - Estimates should be conservative so that we under-promise / over-deliver the majority of the time.
    - Be aware the amount in the pool WILL shift and move as different users drop different amounts of funds in. Playing with the max daily amount is one way we could try to minimize this volatility.
    - Doing different things at different stages of release is an option.
- [ ] Create subsequent tasks for backend implementation and front-end changes.

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
A user should be able to hide a boost and they should not see it again in any boost slots

<!---
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
--->
A user should be able to hide a boost and they should not see it again in any boost slots.


## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

To facilitate a 'not interested' or 'don't show again' feature, we may need to implement a new table to store such data. The boost table would then need to join against this when querying. 

## 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.
--->
Adding to the dropdown of the entity menu (post menu).

## Personas

<!---
Who does this user impact and why (optional)
--->
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.
--->
Use the epic flag.

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [x] Implement rule Boost-22 - "A user should be able to hide a boost and they should not see it again in any boost slots"
- [x] Implement new table to store the hidden entities for each user. Store the guid of the entity, not the boost
- [x] Wire up to the Boost table via a join
- [x] Frontend should display "Hide" button in the dropdown
- [x] Limit the hide action to 5 (config variable) per day unless in Minds+
- [ ] Integration test

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
Do not allow an entity in an accepted boost state to be deleted or edited

<!---
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
--->
It should not be possible to delete or edit a post whilst it is in the Accepted state

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Implement the goal/acceptance criteria

## 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.
--->
N/A

## Personas

<!---
Who does this user impact and why (optional)
--->
Boosters

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->
N/A

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Implement rule **Boost-23** "An activity post can not be edited or deleted when in an Accepted Boost state"
- [ ] Integration test

## Definition of Ready Checklist

- [x] Definition Of Done (DoD)
- [x] Acceptance criteria
- [ ] Weighted
- [x] QA
- [x] UX/Design
- [x] Personas
- [x] Experiments

Story points: 2.0
Filter unmarked expired Superminds from pending queue

<!---
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

Superminds that are still in a state where they can be accepted, can be expired if the time to accept has elapsed runner hasn't updated the state of the Supermind yet.

### Steps to reproduce

Get a supermind with a state that can be accepted (CREATED?) and force the timestamp to be expired - you will still see it in the pending queue of the console.

### Platform information 

Web / Mob

### What is the current *bug* behavior?

Expired boosts still appear and allow users to attempt to accept in many cases - it also messes with count queries which are used to determine whether to show the feed notice indicating a user has pending Superminds.

### What is the expected *correct* behavior?

We should filter by timestamp in the query so only non-expired Superminds are returned for the pending list. (note pending / created terms conflict on front-end and backend)

### 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
Onchain Boost payment process for new dynamic boost system

<!---
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
--->
Allow for onchain boosts to be submitted for the new dynamic boost pricing system

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

We need to confirm that the transaction has not previously been used

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
As acceptance criteria

## 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

## Personas

<!---
Who does this user impact and why (optional)
--->
Boosters

## Experiments

Controlled via https://growthbook.minds.com/features/engine-2475-onchain-boosts

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] A user can pay for their boost via onchain
- [ ] The onchain transaction can only be used once, fraud prevention should be taken into account

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
QA to be able to use stripe in test mode

<!---
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
--->
QA should be able to test with test stripe accounts and cards on the production (staging) environment.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Provide a secure and isolated way for developers and qa to use stripe in test mode. Ordinary users must not be exposed, nor should they be able to take advantage of this. 

Extra configurations will also need to be provided. 

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
Yes

## 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

## Personas

<!---
Who does this user impact and why (optional)
--->
: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.
--->
N/A

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Able to use stripe test creds (if required) on the main minds environments (staging, canary, production)

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Ab

Story points: 3.0
Stripe Checkout: Return redirect url for mobile

<!---
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

We need to apply the same logic as we did on stripe/onboarding for the checkout: return the url and let the client handle the redirection themselves.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

The endpoint should return the redirect url.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

N/A

## 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

## Personas

<!---
Who does this user impact and why (optional)
--->

N/A

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->

N/A

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] api/v3/payments/stripe/checkout/setup returns the redirect url on mobile

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Boost 'ranking' service to ensure fair distribution based on bid price

<!---
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
--->
To aid with https://gitlab.com/groups/minds/-/epics/293, we require a service that paces the boosts based on their respective bid.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

A long running service that is able to rank boosts based on their respective bids. For example if the total bid pool was $100, and I have bid $10, I should receive 10% of all the available views. 


## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
N/A

## 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

## Personas

<!---
Who does this user impact and why (optional)
--->
Boosters

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->
N/A

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Deployed via the new runners helm chart (with argo)
- [ ] Spec tests to ensure the pacer/ranking system works
- [ ] Possible changes to the way we record view for efficiency 
- [ ] Changes to schemas if necessary to support the calculations and rankings

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 8.0