giseldo/neodataset huggingface dataset:
Create new boost v3 module

<!---
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
--->

Backend support 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
--->

Create skeleton and data resources for the new dynamic boost system

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

Integegration tests


## 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 (this is a new backend endpoint)

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] New boost module under Core/Boost/V3
- [ ] API endpoints under api/v3/boost
- [ ] Payment methods working and charging/refunding
- [ ] Schemas agreed and implemented via Repository classes
- [ ] Integration tests

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 8.0
Post to Twitter checkbox and text shouldn't show if a user does not have Twitter OAuth2 connected

### Summary

Post to Twitter checkbox and text shouldn't show if a user does not have Twitter OAuth2 connected. Currently it does. The state of posting should never be reachable if a Supermind DOES require Twitter and the user is not connected.

### Steps to reproduce

1. Login as a user with funds to send a Supermind.
2. Send a supermind to a user without Twitter connection, with the `require Twitter reply` checkbox not selected.
3. Login as user 2 and click on accept offer for the supermind.
4. You should not be prompted to connect to Twitter.
5. Enter supermind reply and Press Send.
6. In the confirmation modal, you should not see the option to cross-post to Twitter, as Twitter is not connected. 

### Platform information 

Web, production.

### What is the current *bug* behavior?

Flow is incorrect

### What is the expected *correct* behavior?

- Post to Twitter option should not be available on Supermind reply if the user does not have Twitter Connected
- If they do, it should be.
- Connect Twitter option should not be shown for a Supermind that does not require Twitter.

![image](/uploads/cc09e0f32825e1ecac541b04ff231e6b/image.png)

### Relevant logs and/or screenshots

![image](/uploads/d432c5bd103daee2e10c26aeb0863c04/image.png)

### Correct UX/UI Designs

![Creator_Reply_Confirmation__Twiiter_Optional_](/uploads/5bf7ec8ce9d872671261dcf302af5d02/Creator_Reply_Confirmation__Twiiter_Optional_.png)
![Creator_Reply_Confirmation__Twitter_Required_](/uploads/0e0074e5a90eb5b1413655debf17cde2/Creator_Reply_Confirmation__Twitter_Required_.png)

Story points: 1.0
Codecept/Playwright test parallelization

<!---
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

Reduce run-time in CI of our E2E suite.

## What needs to be done

Parrellize our Codecept/Playwright tests.

## QA

Check for green light / test stretch.

## UX/Design

N/A

## Personas

Developers

## Experiments

N/A

## Acceptance Criteria

- [ ] Tests running in parallel - threads and workers to be discussed
- [ ] Minimal flake - some tests or low level helpers may need to be rewritten slightly to increase idempotency.

## Definition of Ready Checklist

- [x] Definition Of Done (DoD)
- [x] Acceptance criteria
- [ ] Weighted
- [x] QA
- [x] UX/Design
- [x] Personas
- [x] Experiments

Story points: 1.0
Generate a readable 'description' for all stripe payment intents

<!---
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
--->

Have a human readable 'description' field on stripe payment intents and also display to a user on their receipts. 

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Stripe has a 'description' field that we can set.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
Descriptions are applied.

## 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)
--->
Spenders

## 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
--->

- [ ] New payment intents to generate a readable description such as "Supermind to @mark", "@mark's Bronze Membership", "Tip to @mark", "Minds Plus", "Minds Pro"
- [ ] Script to retrospectively update old payment intents

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Gne

Story points: 3.0
Show cash boost offers at the top of the queue (both admin review and approved feeds)

<!---
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 incentivise cash boosts, deliver them first before token boosts.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
We will need to modify the sort filters for the Elastic repository on boost. 'Cash' boosts should be show first. 

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
TBD

## 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
--->

- [ ] A cash boost is shown before token boosts

## Dev notes

https://gitlab.com/minds/engine/-/blob/master/Core/Boost/Network/ElasticRepository.php#L27

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
A method for developers to change the boost cash 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
--->

Developers need to be able to specify the boost price for cash to control the backlog of boost

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

- In the future this will be dynamic, however for now we need a variable that developers can set without hard coding.

## 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
--->

- [x] Config that developers can set and which updates the boost price
- [x] Support for future dynamic pricing by having a function that returns the price

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Backend support for creating and accepting Cash 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
--->

Allow for boosts to be paid for with cash so that we can increase revenue

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

- Update the boost payment methods to support cash

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

Pay for, accept and reject boosts with cash

## 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.
--->
Yes, for feature flag

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [x] Cash boosts can be made for newsfeed and sidebar boosts
- [x] Cash boosts can **not** be made for boost offers
- [x] Admin api can accept and reject boost offers
- [x] Backend must verify the bid -> view price
- [x] Statement descriptor and description on payment intent referencing the boost
- [x] Feat flagged
- [ ] Integration tests

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
Cannot call export 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

Error being thrown by engine likely relating into the entity hydration feat flag

### Steps to reproduce

Unknown - see Sentry

### Platform information 

Web

### What is the current *bug* behavior?

Error is thrown

### What is the expected *correct* behavior?

Should not throw error out - should it log? to discuss. User may be banned or deleted - need to investigate context.

### Relevant logs and/or screenshots

https://sentry.io/organizations/minds-inc/issues/3697130365/?query=is%3Aunresolved+user.id%3A1424430417754198018&referrer=issue-stream&statsPeriod=14d

### Possible fixes

Need to check if user is null before calling export.

Story points: 2.0
Backend for InApp verification code on 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

<!---
Clearly outline the goal of the issue and why we are doing it
--->

A backend api is required to both send and verify In-App user verification codes

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

- Figure out a schema to store all the code requests by device id
- Hook into the current push notifications system

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

TBD

## 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)
--->
Mobile 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.
--->
N/A (mobile will have the toggle)

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] New module for the verification flow
- [ ] Schemas built out
- [ ] Working API
- [ ] Endpoint to inform if verification has been completed or not
- [ ] Integration tests if possible

## Dev notes

- TTL for request? Parameter. ~15 mins.
- Make another task for S3 data dump
- Happy path etc https://gitlab.com/groups/minds/-/uploads/a395dab183ecba601730f0d679f1f0e4/In-app-registration.pdf
- https://github.com/thiagoalessio/tesseract-ocr-for-php

## Definition of Ready Checklist

- [x] Definition Of Done (DoD)
- [x] Acceptance criteria
- [x] Weighted
- [x] QA
- [x] UX/Design
- [x] Personas
- [x] Experiments

Story points: 8.0
Fix Supermind module testbed conflicts

<!---
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

https://gitlab.com/minds/engine/-/merge_requests/1155 was merged alongside the testbed for the Supermind module and caused unforseen conflicts, as the tests now fail.

### Steps to reproduce

Run unit tests.

### Platform information 

CLI / CI

### What is the current *bug* behavior?

Test failures

### What is the expected *correct* behavior?

Should green light

### 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: 2.0
Update Supermind email to point non-accepted to single Supermind 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

Direct users straight to the single Supermind page rather than just their inbox

## What needs to be done

Update emails to point to a single supermind page rather than just the whole inbox.

## QA

Test emails

## UX/Design

N/A

## Personas

Web

## Experiments

N/A

## Acceptance Criteria

Update links at:
- [ ] - [ ] https://gitlab.com/minds/engine/-/blob/84f946fb60bbf6d529cd63b823759155f357cacf/Core/Email/V2/Campaigns/Recurring/Supermind/Supermind.php#L99

## 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
Supermind console pending feed should be sorted from newest to oldest

<!---
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

Supermind console pending feed should be sorted from newest to oldest

We need to remove the condition reversing the order for inbox AND outbox

### Steps to reproduce

Check pending filtered inbox

### Platform information 

Web

### What is the current *bug* behavior?

Order is showing oldest first, which makes no sense with see latest button

### What is the expected *correct* behavior?

Should show from newest to oldest

### Relevant logs and/or screenshots

N/A

### Possible fixes

Should be some if statements in the repo that can be removed

Story points: 1.0
Optimise and improve development process for playwright tests

<!---
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

Optimise and improve development process for playwright tests

## What needs to be done

Optimise and improve development process for playwright tests

## QA

Run tests

## UX/Design

N/A

## Personas

Developers

## Experiments

N/A

## Acceptance Criteria

Within the timebox, see what we can accomplish from the below list:

- [x] Rebase framework to use standard configs. - recreate with typescript option out of the box.
- [x] Use of DI system. See if this system is suitable when post-rebase.
- [x] Config separation for local and sandbox.
- [x] Retry logic for flake mitigation (3 retries).
- [x] Make timeouts waiting on elements and requests global (but overridable) 30 seconds.
- [x] ​Change naming conventions of misaligned areas to match docs like Components => Fragments, maybe some stuff around helpers too.
- [x] Add scripts to package json for building typescript - maybe even making a Page etc

- [x] Spin up cards for subsequent work such as for parallelization.
- [x] Migrate helpers to actual Codecept helpers. (stretch goal).
- [ ] Rewrite existing tests that are not making use of POMs (stretch goal).
- [ ] Improve any flake that appears during the process (stretch goal).
## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
Make Stripe iframe 500px

<!---
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

Temporary patch for https://gitlab.com/minds/minds/-/issues/3457?work_item_id=116404432

Make Stripe iframe 500px height as a temporary solution to enable users to add their bank cards who have to go through security measures that go beyond the given height of the iframe (I believe it's currently 150px).

### Steps to reproduce

Try enter a card with 3DSecure - unsure how to effectively replicate this with test cards.

### Platform information 

Web

### What is the current *bug* behavior?

Stripe iframe is too short to complete for some users with some banks.

### What is the expected *correct* behavior?

Height should be taller

### Relevant logs and/or screenshots

![image](/uploads/bb2c5d8fe98987dfb5d8a0590cffdaf1/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 unit test coverage for Supermind module

<!---
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 test coverage for Supermind module.

## What needs to be done

Unit test core parts of the Supermind module.

## QA

Check unit tests pass.

## UX/Design

N/A

## Personas

Developers

## Experiments

N/A

## Acceptance Criteria

- [ ] Improved test coverage of areas like Manager and Repository.

## 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
Cannot send tokens to a user who has no account connected

### Summary

Sending tokens to a user who does not accept cash should be allowed.

### Steps to reproduce

1. Open web app.
2. Login successfully.
3. Navigate to a channel with no account.
4. Select superminds.
5. Tap Tokens.

### Platform information 

Chrome

### What is the current *bug* behavior?

Throws error

### What is the expected *correct* behavior?

Should let you send tokens

### Relevant logs and/or screenshots

![image](/uploads/fc89ec383719dabd02b51a3b8c979a9e/image.png)

Story points: 1.0
Sending superminds is throwing Internal Server Error

### Summary

Tapping the superminds send button when you have drafted a superminds post, throws Internal Server Error. 

### Steps to reproduce

1. Go to any channel (with or without bank account connected)
2. Tap on Superminds.
3. Enter Superminds details and set it to cash. 
4. Agree to terms and hit save.
5. Compose a post.
6. Hit Send.

### Platform information 

Chrome - Staging/Sandboxes

### What is the current *bug* behavior?

Internal server error appears

### What is the expected *correct* behavior?

Should see an error saying 

`X is unable to receive payments at this time`

### Relevant logs and/or screenshots

Logs: https://sentry.io/organizations/minds-inc/issues/3590369693/?query=is%3Aunresolved

![image](/uploads/d037f89273b8339c7e91c664d76c18ce/image.png)

Story points: 1.0