giseldo/neodataset huggingface dataset:
Clicking on the dropdown overlay navigates to the post

<!---
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

This is a regression caused by https://gitlab.com/minds/front/-/merge_requests/2002. After opening the dropdown, clicking anywhere (the overlay) will navigate to the post.

### Steps to reproduce

- The following actions cause navigation instead of their default behavior
  - dismissing the activity dropdown
  - dismissing the Quote dropdown
  - subscribing/unsubscribing from the channel publisher card
  - clicking See more

- also notice that the activity will keep being highlighted even after moving the cursor outside of the post

Potentially a different issue, but still related to !2002 

- The radius around buttons is small for upvotes, downvotes, comments, reminds, tips and boosts etc, so if you miss by 1-2 pixels, you open modal. We need to introduce a larger clickable area for most buttons on the activity
- Clicking play on native videos was previously opening modal, now it goes to post page
- Unlocking NSFW posts

### Platform information 

browser

### What is the current *bug* behavior?

- clicking on the overlay causes navigation
- activity is highlighted even though cursor is outside

### What is the expected *correct* behavior?

- clicking on the overlay should dismiss the dropdown
- activity should not be highlighted if the cursor is outside of it

### Relevant logs and/or screenshots

![Screen_Shot_2022-09-06_at_10.32.02](/uploads/c52aa752e9b0fc8c3c256e7dd0be8a65/Screen_Shot_2022-09-06_at_10.32.02.png)

![Screen_Shot_2022-09-06_at_10.59.54](/uploads/fcf94360e64d711c826562cf0471faa1/Screen_Shot_2022-09-06_at_10.59.54.png)

![Screen_Shot_2022-09-06_at_11.01.38](/uploads/6fbad57bf25b39854a930b1b8e3322a4/Screen_Shot_2022-09-06_at_11.01.38.png)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 2.0
Update buttons on activity posts

## Goal

Re-arrange and add buttons to the activity post to enable introduction of Superminds.

## What needs to be done

- Add Supermind button to the action bar
- Remove Tip button from the action bar
- Move Tip functionality to the top-right ... dropdown menu

![image](/uploads/6e82930653c5f040f93d57955603708e/image.png)

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

- [Figma: Visitor view](https://www.figma.com/file/thrGepQAxmcMGB7MoEEckM/Supermind?node-id=295%3A10153)
- [Figma: Post owner view](https://www.figma.com/file/thrGepQAxmcMGB7MoEEckM/Supermind?node-id=295%3A9679)

## Personas

Everyone

## Experiments

n/a

## Acceptance Criteria

- [x] The action bar contains buttons for: Upvote, Downvote, Remind, Comment, Supermind, Boost [for your posts]
- [x] The ... dropdown menu contains a button for Tipping
- [x] Add data-ref tag to new Supermind button to aid analytics

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Enable activity-v2 media modals to display multi images

<!---
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 backend support for multi images, we want these images to open up in the media modals.

See https://gitlab.com/minds/front/-/merge_requests/2020

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

On click, open the image in a media modal

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

Media modal should paginate between the images

## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

https://www.figma.com/file/KlhBWJ05RhiYiYp66CiAb9/Multi-Image-Concept?node-id=17%3A1256

## Personas

<!---
Who does this user impact and why (optional)
--->

Creators and 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.
--->

N/A

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Images should on in the media modal
- [ ] Pagination to be disabled (removed) from existing entity<->entity flow
- [ ] Playright test

## 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
Email code modal doesn't always auto-appear on register

<!---
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

Email code modal doesn't always auto-appear on register

### Steps to reproduce

1. From a logged-out state where you are not in an experiment.
2. Login, with a user state where you are IN the experiment (trial and error is going to be the only way to do this).
3. Observe no modal.

### Platform information 

Web

### What is the current *bug* behavior?

Modal doesn't appear automatically in a permutation of logged in / logged out experiment values for the email code experiment.

### What is the expected *correct* behavior?

Email code modal should appear if you are in the email code experiment

### Relevant logs and/or screenshots

N/A

### Possible fixes

Check app.component.ts

Story points: 1.0
Force vote down button to wait for server response

<!---
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

Race condition can occur with votes, we should be awaiting a response before continuing.

### Steps to reproduce

Downvote and remove downvote quickly

### Platform information 

Web

### What is the current *bug* behavior?

Race condition.

### What is the expected *correct* behavior?

Force client to wait.

### 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

Force client to wait.

Story points: 1.0
Add back button to single activity page if redirected from hover click

<!---
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
--->
Idea from @benhayward.ben :
Make it easy to go back to the feed when a user navigates to a single activity page via the hover click functionality.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
- add a back button to single activity page if they got there from somewhere else on the site (i.e. NOT by entering the url directly into the browser or navigating from an external site)
- back button should bring them back to the same location they were before they clicked

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
- Make sure back button doesn't show up unless it is supposed to
- make sure when back button is clicked, the feed location is correct. (note: feed locations aren't working, it will just go back to the previous 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.
--->
copy twitter

## Personas

<!---
Who does this user impact and why (optional)
--->
Users who click on posts 

## 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] back button appears when appropriate
- [x] back button navigates to correct location
- [x] re-use the discovery (via for-you tab and search) back button

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Implement Supermind settings

<!---
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
--->
- Build out settings screen for users to manage Supermind related settings such as minimum offer thresholds 

## What needs to be done

Create a new section of user settings that enables a user to edit their minimum offer amounts for Superminds.

### Backend logic

For simplicity, save the supermind settings to user entity as a denormalized configuration field. 

## 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.
--->
* Prototype - [Settings Prototype](https://www.figma.com/proto/thrGepQAxmcMGB7MoEEckM/Supermind?page-id=287%3A5127&node-id=292%3A6889&viewport=857%2C575%2C0.13&scaling=min-zoom&starting-point-node-id=292%3A6889&show-proto-sidebar=1)
* There is no ability to enable or disable this feature.
* SuperMind will be available to all users.
* SuperMind settings is contained within `Settings` > `Account` and offers the user the ability to define a minimum offer amount for both USD and Tokens.
* Where the user does not have a connected bank account, they will be prompted from within settings to connect their bank account, before then being able to define a minimum USD offer.
* SuperMind settings will be linked also from the `SuperMind console`. Make sure to update link at `src/app/modules/supermind/console/console.component.ts`


## Personas

Creators

## Experiments

n/a

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [x] Add options for token and USD minimums in Settings using existing backend endpoint
- [x] Default to: 1 token, 10 USD
- [x] Prevent user from entering values lower than: 1 token, 10 USD
- [x] Backend logic

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
Retire legacy 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
--->
The legacy module contains stuff that is actively being used. We should move the components to appropriate places and get rid of the legacy name.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
- move components out of legacy module
- delete legacy module and references

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
Make sure site builds and the (formerly) legacy components still work as they have been working

## 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)
--->
devs

## 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
--->

- [ ] legacy module removed

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
Tip and Boost buttons are white in staging (Dark Mode)

<!---
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

![image](/uploads/fc31173aa3b6e478848dbeeef72c23aa/image.png)

![image](/uploads/49db4317a716859507bae619fe0c517a/image.png)

![image](/uploads/8766c7b5f6b1470a3d4026a7bdbebb8b/image.png)

![image](/uploads/88e9b236018bdca1c563f2815677bd87/image.png)

### Steps to reproduce

1. Turn on staging
2. Go to feed

### Platform information 

Affects v1 and v2 activities in Staging

### What is the current *bug* behavior?

Wrong background on tip and boost buttons.

### What is the expected *correct* behavior?

Correct background on tip and boost buttons, that blends in.

### Relevant logs and/or screenshots

up

Story points: 1.0
Notifications/v3 page does not load properly on mobile

### Summary

Found by @ottman 

### Steps to reproduce

1. Open minds.com/notifications/v3
2. Notice the UI is not aligned and empty page shoes up

### Platform information 

iPhone 11 Pro - Chrome

### What is the current *bug* behavior?

UI is not correctly visible

### What is the expected *correct* behavior?

UI should look like a notifications page

### Relevant logs and/or screenshots

![image](/uploads/d4f33069802b7a16626ac1c19f91d946/image.png)

Story points: 1.0
[Automation] Spike: Convert Playwright tests to Typescript

## Goal

Investigate on converting JS to TS for Playwright tests. 


## What needs to be done

Make sure all integrations below still work:
- CodeceptJS
- Gherkin
- Page Object Model
- Browserstack


## QA

Test locally & CI


## UX/Design

N/A

## Personas

N/A

## Experiments

N/A

## Acceptance Criteria

- [ ] Tests pass in CI

## Definition of Ready Checklist

- [x] Definition Of Done (DoD)
- [x] Acceptance criteria
- [x] Weighted
- [x] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
[Automation] Spike: Codeceptjs Playwright with Code Coverage tools

## Goal

Research spike on figuring out how to determine automation coverage automatically.


## What needs to be done

Investigate on integration with tools like Istanbul and more.


## QA

Test locally and CI


## UX/Design

N/A


## Personas

N/A


## Experiments

N/A


## Acceptance Criteria

- [ ] Integrate with a test coverage tool

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

[]

Story points: 2.0
Adjust the way activity content components handle paywalls

<!---
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
--->
#5697 revealed a weakness in how the activity content component handles `showPaywall` and `showPaywallBadge`. They are currently passed as inputs to the content component, but they should be grabbed from the activity service, _inside_ the content component.

![image](/uploads/63e83e707b99633a32064d602b161d1e/image.png)

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
- Get those two inputs from within the content component instead of passing them via the parent

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
- paywalled posts and badges should be reviewed

## 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)
--->
Devs (reduce room for error in development). Users who view activities.  

## 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
--->

In the activity content component
- [ ] activity v1: `showPaywall` is input is replaced with a subscription to `activityService.shouldShowPaywall$`
- [ ] activity v1: `showPaywallBadge` input is replaced with a subscription to `activityService.shouldShowPaywallBadge$`
- [ ] activity v2: `showPaywall` is input is replaced with a subscription to `activityService.shouldShowPaywall$`
- [ ] activity v2: `showPaywallBadge` input is replaced with a subscription to `activityService.shouldShowPaywallBadge$`

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Make a test channel who has posted every variation of activity type

<!---
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
--->
Create a feed that contains all the different permutations of posts (rich-embed, status, image, video, quote, remind, paywalled+locked, paywalled+unlocked, nsfw, long text, short text, has title, etc. - [see spreadsheet](https://docs.google.com/spreadsheets/d/1JrOPTSziDAubeziV8pR-nnxJI_6ko6SGxk2s9rEtiag/edit#gid=0)). This way anyone who is working on changes to activities can scan through it and get a good idea of what they're working with and what has changed, instead of having to search around the site and find examples. 

Consider making a pair or trio of channels so we can see the posts from all permutations of access (e.g. channel A has a bunch of different posts. log in to channel B to see those posts when paywalls are locked, log in to channel C to see those posts when paywalls are unlocked. 

The channel's "about" info should contain guidelines on adding content to the feed and using the channel for testing.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
- Make a list of the types of activity posts we want to see 
- Create a test user with a name that's easy to remember and create posts based on the list above. Share password in a secure location.
- Share the test user name with the team

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
None

## 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)
--->
Dev

## 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
--->

- [ ] list of permutations created
- [ ] channel created with posts
- [ ] info shared with team

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 0.0
Persistent Feeds: release behind a feature flag

<!---
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 up from https://gitlab.com/minds/front/-/issues/5333, this issue attempts to make the persistent feed deliverable

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

We should make sure the new persistent feed feature is deliverable and all functionalities associated with it are put behind a feature flag.


## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

We need a feature flag for this and the changes will only be applied to the main newsfeed (top/latest)


## 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)
--->

All 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.
--->

Required

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Persistent feed is behind a feature flag

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0