giseldo/neodataset huggingface dataset:
Unread notifications email links to broken page

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

The `You have unread notifications` email links to a minds.com URL that doesn't work.

https://mobile.minds.com/notifications/v3

### Steps to reproduce

- Receive a `You have unread notifications` email
- Click the `View all notifications` button at the bottom of the email

### Platform information 

- Tested on MacOS + Chrome

### What is the current *bug* behavior?

- The minds.com page partially loads, but the content doesn't fill out

### What is the expected *correct* behavior?

- The user is brought to a page with all of their notifications

### Relevant logs and/or screenshots

![image](/uploads/d00630664d933848fe5ae1b01ee1b1c1/image.png)

### Possible fixes

Replacing `mobile` `mobile.minds.com` with `www` (`www.minds.com`) appears to load as expected.

Story points: 1.0
Backend support for displaying channel subscriber relationships

<!---
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

Unblock two frontend tasks related to presenting relevant subscription relationships.

- https://gitlab.com/minds/minds/-/issues/3012
- https://gitlab.com/minds/mobile-native/-/issues/4313

![Mutual_subscriptions__Definition](/uploads/61f0532f6f965e84534c273ecc910dd0/Mutual_subscriptions__Definition.png)

## What needs to be done

Create backend support to return data that enables the frontend tickets listed above.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

No design.

## Personas

- Minds dev team

## Experiments

No experiement

## Acceptance Criteria

- [ ] There is a backend service that can support the tickets linked above.
- [ ] Return a list of channels that subscribe to the channel in question, that I am also subscribed to. ie. mutual subscribers
- [ ] Create a mechanism to keep cassandra friends table in sync with new vitess table
- [ ] Spec tests
- [ ] If no matches found, return 200 with an empty array of users.

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
Prompt with confirm box before acting on boost

<!---
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
--->

The goal is to eliminate finger slip and double-tap errors in the admin boost queue.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Force a confirm box before accepting or rejecting a boost:

## QA

Test confirm box when accepting/rejecting a boost

## UX/Design

A simple alert like

![image](/uploads/d134233bdb5175e750ff2c48c2db6b0a/image.png)

## Personas

Admins, to aid in the prevention of slips.

## Experiments

N/A

## Acceptance Criteria

- [ ] Boosts shouldn't be able to go through without confirming in a confirm box popup.

## 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
Backend support for activity posts with multiple media attachments

<!---
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

Support activity posts with multiple images to enable content creators to create content they expect to create on social media.

## What needs to be done

Set up backend to support a new activity post type that contains multiple images. Some assumptions we can make:

- A post can have multiple images (1-4).
- All upvotes / engagements on images within the post are attributed to the post -- in other words, the activity post has one set of engagements; we do not store engagements separately for each image within the post.

Activity:

```
->custom_type = 'batch';
->custom_data = [
  [
     // image one
     'thumbnail_src' => < source to thumbnail 1>
  ],
  [
    // image two
    'thumbnail_src' => < source to thumbnail 2>
  ]
]
```

Album:

```
// TODO:
```

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

Front end design of the multi-image posts is still in progress. Michael and/or Ryan can walk through in-progress designs if necessary.

## Personas

- Core Minds creators

## Experiments

No experiment

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [x] The backend supports a new activity post with multiple images
- [x] Agreement on data structure
- [x] Proof of concept of working

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 8.0
Change email schedules

<!---
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

When a user signs up for a new account, we automate some emails to onboard them into different features on Minds. One is the `Get paid for your posts on Minds` email, which is sent a day after they sign up.

However, we're testing a change to when users are able to join events, a change that puts a 3-day account age requirement ahead of joining rewards.

The goal is to keep the email messaging consistent with the site messaging.

## What needs to be done

Change the timing of the `Get paid` email to be sent 3 days after they've signed up.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

No design changes.

## Personas

This impacts new users who may be interested in Rewards.

## Experiments

This change blocks another experiment, but otherwise no experiment.

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Change Bring your Friends email to be on day 1
- [ ] The `Get paid for your posts` email is sent to new users 3 days after they sign up

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Conditional 2FA required modal title

<!---
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

Changing title in email code confirmation modal from 2FA Required in the modal to Confirm Your Email would make more sense

## What needs to be done

Change title if the user does NOT have an email confirmed in the session service (or email confirmation service?) to 'Very email'

## QA

Check modal title is appropriate before and after email confirmation.

## UX/Design

N/A

## Personas

Onboarding users

## Experiments

Ties into email code experiment but is not a standalone experiment.

## Acceptance Criteria

- [ ] Change title and other relevant copy dependant on whether session is confirmed
- [ ] Unit tests

## 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
Browser notifications prompt follow-up

<!---
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

Following up the recent browser notifications prompt change (https://gitlab.com/minds/minds/-/issues/3111) with small changes to reduce user confusion.

- More clearly communicate the distinction between push notifications the user is enabling and the notifications they're currently reading
- Don't display the prompt for users on browsers that aren't compatible with the feature.

## What needs to be done

Change the copy that appears in the component to `Enable push notifications for this device`

Display the prompt only for browsers that support our push notifications.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

No design (just copy change described above).

## Personas

Core users

## Experiments

No experiment.

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Change the copy that appears in the component to `Enable push notifications for this device`
- [ ] Double check display the prompt only for browsers that support our push notifications. (Do not sure for Brave).

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Automate post-signup survey for lapsed users

<!---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

Get a consistent flow of feedback from users who sign up for Minds

## What needs to be done

Automate an email to go out to users who sign up for Minds accounts, 7 days after registration. The email should link users to a survey where they can provide feedback that we can use to better understand how to serve new users coming to Minds.

Match the email design linked below.

- Email subject: What do you think of Minds?
- Preview text: Positive or negative, we'd love your feedback.͏‌
- CTA: Quick Survey
- CTA link: https://mindsdotcom.typeform.com/to/n6Sj3qsg#segment=0
- Headline: What do you think?
- Body copy:

> Hey @username! Thanks for joining Minds to help us elevate the discourse through Internet freedom.
> 
> Whether positive or negative, we'd love hear your feedback about your experience on Minds so far. It will only take a few moments, and the information you provide will help improve our service.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

- [Litmus designs](https://litmus.com/pub/eb83d00)
- Screenshot below for easy reference -- but if different from the Litmus link above, use the Litmus link as source of truth.
- [Download Email Assets](/uploads/cb744a1876d13bb3e6291f5d5c45dbb1/First_impressions_questionnaire__lapsed_users_.zip)

![image](/uploads/934a9cc5c5a258977e37963027d5763b/image.png)

## Personas

- Users who signed up for Minds but didn't end up sticking around; curious users

## Experiments

No experiment

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Given a user has signed up for Minds and verified their email address, when 7 days have passed, then the user receives an email prompting them to complete a survey
- [ ] The email includes a CTA link to the Typeform survey linked above

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Add notification setting for Community 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

Give users control over whether or not they receive ad-hoc push notifications via our new ad-hoc tool

## What needs to be done

Add a setting to the existing settings screen for `Community updates`.

Default the setting to on.

The setting determines whether or not the user receives ad-hoc push notifications.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

No new designs -- this should use the same component design for existing notification settings.

## Personas

Core users.

## Experiments

No experiment

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] A new `Community updates` option is added to the Settings > Notifications screen
- [ ] Add to https://gitlab.com/minds/engine/-/blob/master/Core/Notification/Settings/PushSettings.php#L35
- [ ] The setting defaults to `on`.
- [ ] Given the user has notifications enabled, and the setting for `Community updates` is ON, when a notification is sent through the new ad-hoc tool, then the user does receive the notification.
- [ ] Given the user has notifications enabled, and the setting for `Community updates` is OFF, when a notification is sent through the new ad-hoc tool, then the user does NOT receive the notification.
- [ ] Admin system push notifications to respect the flag
- [ ] Added by Ben: Notif added in https://gitlab.com/minds/engine/-/merge_requests/1030 should be respected
## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Measure click events for Channel feed controls

<!---
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

Goal is for the team to understand how often users engage with the feed controls on Channel pages, including the Type control and the Date control.

![image](/uploads/347002bd642ba92940a2419c6aa3a96a/image.png)

## What needs to be done

Add click refs to the feed control menu items so that our click event system measures these clicks.

| Feed control     | Suggested ref value      |
|------------------|--------------------------|
| Type: All        | feedcontrol-type-all     |
| Type: Images     | feedcontrol-type-images  |
| Type: Videos     | feedcontrol-type-videos  |
| Type: Blogs      | feedcontrol-type-blogs   |
| Date: All time   | feedcontrol-date-alltime |
| Date: Date range | feedcontrol-date-range   |

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

No design implications.

## Personas

This change is for product analytic use.

## Experiments

No experiments.

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Feed controls on channel pages have click ref attributes
- [ ] Existing click measurement picks up clicks on the feed controls outlined above
- [ ] Click events are matched to anonymized user IDs

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Fire analytics event when a user reaches the end of a feed

<!---
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 want to understand how often users reach the end of feeds, and in what context they reach the end of feeds so that we can identify and prioritize solutions

## What needs to be done

Fire an analytics event when a user reaches a "Nothing more to load" message in a feed.

This can happen in:
- Newsfeed
- Channel feed
- Discovery feed
- Search feed
- Group feed
- (and other places)

The event should pass context that allows us to discern:
- Where did the user encounter the end of a feed? Which page / type of feed?
- Which platform was the user on?
- How many posts were they served before seeing the end of the feed?

### The refactor

Deprecate the use of 'click_event'. Replace this with a new event called 'generic_event".

| name | type | example |
| ------ | ------ | ------  |
| event_type | string | eg. 'click', 'view' |
| event_ref | string | eg. 'topbar-link' |

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

No design requirements for this.

## Personas

This change impacts the internal Minds team (Data team and Product Management).

## Experiments

No experiment for this.

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] On any given feed, when a user encounters a "Nothing more to load" message, an event is fired
- [ ] The event passes sufficient context to answer questions identified above
- [ ] Introduce a new 'generic_event' schema and send events when viewed (must be on screen)
- [ ] Refactor instances of 'click_event' to use the new 'generic_event' schema
- [ ] The data can be analyzed in Superset

## 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: 5.0
Implement media engagement metrics (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're defining a general content engagement metric that counts interactions with media posts. We need to be able to measure when these interactions happen.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Create new analytics events that fire when a user interacts with media in the following ways:

- [ ] Clicks to unmute an autoplay video

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

No design changes.

## Personas

Minds staff and data team.

## Experiments

No experiment needed for these changes.

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Analytics events fire each time one of the above-listed actions is performed
- [ ] Events are related to the activity post IDs that the user is interacting with
- [ ] Events are matched to anonymized IDs of the users performing the engagement
- [ ] Use the 'click_event' schema that we use on the frontend

## Definition of Ready Checklist

- [x] Definition Of Done (DoD)
- [x] Acceptance criteria
- [x] Weighted
- [ ] QA
- [x] UX/Design
- [x] Personas
- [x] Experiments

Story points: 2.0
Email 2FA modal generates confusing messages

<!---
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

The email 2FA modal on web generates some confusing messages, in two scenarios:

1. When the user clicks `Resend` button, then a toaster is displayed with the message `TwoFactor is required`
2. When closing the 2FA  modal, then a toaster is displayed with the message `TypeError: cannot read properties fo undefined (reading 'status')

### Steps to reproduce

Issue #1:

1. Log into an account that does NOT have app-based 2FA configured
2. Navigate to Account > Password screen (https://www.minds.com/settings/account/password) on web
3. Start to change the password by filling in your current password + specifying a new one
4. Click "Update Password" to generate the email 2FA modal
5. Click the `Resend` button.

----

Issue \#2:

1. Log into an account that does NOT have app-based 2FA configured
2. Navigate to Account > Email Address (https://www.minds.com/settings/account/email-address) on web
3. Change the email to anything else => fill in your password
4. When the email 2FA modal pops up, dismiss it
5. Notice the toast error that says `TypeError: Cannot read properties of undefined (reading 'status')` (img 2)

### Platform information 

MacOS + Chrome

### What is the current *bug* behavior?

Issue #1:
- A new verification email is sent, and the modal flashes, and the toaster message `TwoFactor is required` is displayed

### What is the expected *correct* behavior?

~- A new verification email is sent and the toaster message communicates that the email was sent.~

Handling in https://gitlab.com/minds/front/-/issues/5512 - this is a wider issue than just the error message being incorrect.

Expected behavior
- Get rid of superfluous "TwoFactor required" message (as discussed in sprint planning)
- Fix other error dev error message mentioned above

### Relevant logs and/or screenshots

Clicking `Resend` generates `TwoFactor is required` toaster message.

![image](/uploads/03635ef30d63b7ef233d94eece552757/image.png)

Closing the modal generates this toaster message.

![image](/uploads/c00e8f363594f19c948e038ab4ecde55/image.png)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 2.0