giseldo/neodataset huggingface dataset:
Provide 'description' on payment intents to be descriptive

<!---
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
--->

We are currently not sending a 'description' field with our payment intents (stripe). This means that our receipts just say 'Payment to Minds, Inc.'. Provide an informative description. 

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Add statement descriptors for different minds services payment intents. Requirements for the card are Supermind, Membership and Tip - Plus Pro and Withdrawal are bonus items - if they're going to cause the card to go overweight we should split into another card.

```
Minds: Supermind
Minds: Membership
Minds: Tip
Minds: Plus sub
Minds: Pro sub
Minds: Withdrawal
```

## 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)
--->

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
--->

- [ ] The description supplied in Payment Intents are informative

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Common User Configurations Repository

<!---
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
--->

Following on from https://gitlab.com/minds/engine/-/issues/2427#note_1117620482, we now can proceed with creating a common user configurations table. This will make it easier to maintain user state on the backend and not rely on the client side. 

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Below is an example schema.
```
CREATE TABLE IF NOT EXISTS user_configurations (
    user_guid bigint,
    my_example_value float,
    terms_accepted_at timestamp,  
    PRIMARY KEY (user_guid)
) ENGINE=InnoDB;
```

## 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)
--->

Developers

## 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
--->

- [ ] Manager/Repository/Models are created and extensible
- [ ] Create, Update and Read operations 
- [ ] New spike task created for handling schemas

## 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: 3.0
Supermind expiring soon push & in-app notifications

<!---
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
--->
Trigger push & in-app notifications when a supermind request is expiring soon.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Connect the notification work done in #2409 with the expiring soon cronjob work done in #2432. Both of these issues should be completed before starting this one. 

Probably by linking the push notifs stuff with the `ACTION_SUPERMIND_REQUEST_EXPIRING_SOON` event consumed in SupermindEventStreamsSubscription.php

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
make sure the notifications send 

## 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)
--->
supermind 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.
--->
supermind experiment

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [x] in-app notification sent when supermind expiring soon
- [x] push notification sent when supermind expiring soon

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Prevent Supermind Replies from also sending out Quote post notifications

<!---
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

Currently Supermind Replies also send out Quote post notifications

### Steps to reproduce

Send a Supermind Reply with the notifications change in place.

### Platform information 

Platform agnostic.

### What is the current *bug* behavior?

2 notifications sent for same action.

### What is the expected *correct* behavior?

Should only see Supermind reply notification, not quote.

### Relevant logs and/or screenshots

![image](/uploads/2502058db6475a70382e82bf1e7b91ea/image.png)

### Possible fixes

Add supermind context to ActionData https://gitlab.com/minds/engine/-/blob/master/Core/Feeds/Activity/Delegates/NotificationsDelegate.php

Story points: 2.0
Plus overview returning no entities for front

<!---
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

Plus overview is returning no entities for front.

### Steps to reproduce

1. Go to https://www.minds.com/discovery/plus/overview
2. Observe no entities 

### Platform information 

Web

### What is the current *bug* behavior?

No entities returned by endpoint https://www.minds.com/api/v3/discovery/trends?plus=true

### What is the expected *correct* behavior?

Entities should load

### Relevant logs and/or screenshots

![image](/uploads/489a214e2ee21830ca6120a564ceb750/image.png)

### Possible fixes

One interesting thing is that it works fine from mobile - possibly a different endpoint?

Story points: 2.0
Store Supermind reply activity guid in SupermindRequest entity and use it in email template

<!---
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
--->
See issue title.


## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
When a Supermind request is accepted and the reply activity is created, we need to store the reply's activity_guid in the SupermindRequest so we can use it to populate the link of the action button in the `supermind_request_accepted` email.  The button is in the designs (see https://gitlab.com/minds/engine/-/issues/2395) but we had to remove it until the activity_guid is accessible when the email is triggered. 

To enable, uncomment the lines pictured below and on line 109 change `getActivityGuid()` to use `getReplyActivityGuid()` (or whatever it will be called).  

![image](/uploads/d2f1ca5cea7cb273cbe450ba54c255e9/image.png)

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
Reply activity guid is correct and the email action button goes to the activity page

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->
n/a

## Personas

<!---
Who does this user impact and why (optional)
--->
supermind 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

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->
- [ ] supermind reply activity guid added to SupermindRequest entity
- [ ] `supermind_request_accepted` email has a working "view reply" action button

## 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
Cronjob to send emails and push notifications 24hrs before Supermind expires

<!---
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
Set up a chronjob to send an email to Supermind receiver if there is 24hrs left to reply and they haven't made a reply yet. 

<!---
Clearly outline the goal of the issue and why we are doing it
--->


## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
The email template is already created, and is built in /engine/Core/Email/V2/Campaigns/Recurring/Supermind/Supermind.php (topic is `supermind_request_expiring`). When it is ready to be sent, send it the same way the others are sent (see Core/Supermind/SupermindEventStreamsSubscription).

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
Make sure the email sends 24hrs before the Supermind expires, but only if the receiver hasn't replied yet.

## 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)
--->
Supermind 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 (if Superminds aren't enabled already, the email won't send)

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Cronjob and runner to execute every hour
- [ ] Supermind expiring reminder email sends to receiver 24hrs before expiry
- [ ] Trigger push notification via https://gitlab.com/minds/engine/-/issues/2409

## 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: 3.0
Analysis of integration with Unstoppable Domains

<!---
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
--->

Analyze integration with Unstoppable domains and determine complexity.


## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Research reverse resolution on UD documentation to understand requirements for Minds to implement ability for ETH addresses to be read as UD domains. 

https://docs.unstoppabledomains.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)
--->

- 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
--->

- [ ] Determine weight of task to implement UD support

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Anal

Story points: 1.0
Analyze best way to make all Minds transaction receipts downloadable

<!---
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
--->

Analyze best way to make all Minds transaction receipts downloadable so that we have good records of our communication with customers for disputes, and so customers can easily export any transaction receipts.


## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

This task is a placeholder so we can analyze different options and come up with a plan.


## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

Can a user download their receipts?


## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

TBD


## Personas

<!---
Who does this user impact and why (optional)
--->

- Customers
- 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.
--->

N/A


## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Is a user notified when they complete a transaction with Minds?
- [ ] Is a user able to download a receipt of their transaction?
- [ ] Is an admin able to download a receipt of any user transaction?

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Add ACL check for Blocked Channels on Superminds

## Goal

Determine what ACL requirements need to be followed for below cases:
1. Can you supermind to a user who has blocked you?
2. Can you supermind a user who you have blocked?


## What needs to be done

Update function logic based on requirements decision on the questions above. 

Currently the functionality is:
1. Allowed even though it says you should not be able to interact with them. 
![image](/uploads/edefdb6fe2ae5286303fc7242fe6029f/image.png)
2. Not see supermind option on user channel you have blocked. 


## QA

Test superminds security with blocked channels. 


## UX/Design

N/A


## Personas

N/A


## Experiments

N/A


## Acceptance Criteria

- [ ] Add logic for determining what behavior will be there for superminds for blocked channels
- [ ] Do we need to do this for banned channels?

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
[Spike] Gather requirements and analysis for storing user configurations

<!---
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
--->

There are often requests to save user settings, currently we attach these to the user entity or create new implementations per service, however this adds bloat. To simplify this, we wish to have a central user configurations endpoint. 

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Investigate how this could be used by other features and what technologies would be the most appropriate. 

## 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)
--->

Developers :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
--->

- [ ] Tech analysis

## 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: 3.0
Supermind API initial Integration 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

<!---
Clearly outline the goal of the issue and why we are doing it
--->


## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Add initial integration tests for Supermind API to cover main scenarios.

Scenarios to be added

## 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.
--->


## 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
--->

- [ ] Create integration tests for Supermind API

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Set Supermind requests as expired after 7 days from creation

<!---
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
--->


## 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.
--->


## 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
--->

- [ ] Create cli job to update the state of a Supermind request to expired after 7 days from creation if it has not been accepted yet.

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0