giseldo/neodataset huggingface dataset:
Permaweb E2E tests

<!---
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

(Summarize the bug encountered concisely)

### Steps to reproduce

(How one can reproduce the issue - this is very important)

### Platform information 

(Browser, device, system stats, screen size)

### What is the current *bug* behavior?

(What actually happens)

### What is the expected *correct* behavior?

(What you should see instead)

### Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's very hard to read otherwise.)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 1.0
Reminding is broken on newsfeed pages

<!---
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

Big thanks to Chesschats for pointing this one out to us.
https://www.minds.com/newsfeed/1137736597458186240

When you remind from a newsfeed page, it doesn't create a remind - it creates a copy of the original entity, down to the GUID.
This causes strange behaviours around the area of commenting and notifications - if you delete it also breaks things. If you delete the secondary post, it leaves the original post but removes the actual media.

If you do it with text in the remind box, it actually saves as the description of the new post. It is getting posted to the api/v2/newsfeed/remind/x endpoint.

### Steps to reproduce

1. Make a post with an image
2. Click timestamp to go to newsfeed page
3. Remind
4. Check your channel, see the post is cloned, not a remind.
5. Mouse over the timestamps to see the guids in the URLs are identical.

### Platform information 

Initially reported on iOS Safari tablet 
Replicated Firefox Ubuntu

### What is the current *bug* behavior?

Post is cloned, not reminded

### What is the expected *correct* behavior?

Reminding should work like everywhere else on the site.

### Relevant logs and/or screenshots
v (after reminding, 2 clone posts) v
 
![image](/uploads/f88ad926aaff4a144a70e177cefd89e4/image.png)

v (after deleting one) v 

![image](/uploads/a7c80ce260098f813e52d615dc55102d/image.png)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 2.0
Require login for pages that are currently set to noindex

In order to continue the pressure on reducing spam, this ticket proposes to introduce a **login gatekeeper** to all content or channels that have low interaction. 

- **All content** will still be accessible to the network once logged in.
- **Verified** channels should be exempted from this restriction
- **Post owners** should be made aware that their content is not accessible to logged out users

## Content that is currently placed in noindex

- **channels**: fewer than 5 subscribers
- **blogs**: fewer than 5 votes
- **newsfeed/media**: fewer than 5 votes

## Messaging

**Please login or create a channel to view this content**.

(the login form should be inline and not require refreshes or redirects).

## Complications

- Posting to 3rd party networks (facebook, twitter) could have issues with caching

## Additional benefits

- More users create accounts

## Tasks

- [ ] Introduce gatekeeper to strategic pages (newsfeed single pages, blogs, channel feeds)
- [ ] For og:title tags, still provide the metadata so that caching is not a concern.

Story points: 2.0
The new membership tier warning link should open in a new tab so you don't lose tier inputs

If you are creating a new membership tier but haven't set up your bank account yet, when you click the link you lose everything you just wrote for your membership. It should open in a new tab (same for the 'set up token address' warning)

OR the whole form should be disabled until you at least set up your cash account

![image](/uploads/7622cddb44ce4a068f9291e9a9f9ba59/image.png)

Story points: 1.0
Wallet 'scroll to settings' not working

In wallet onboarding, when you click "2. Add your on-chain address", the screen should scroll down to the bottom so that the "on-chain address" input is visible. Currently clicking on the link is doing nothing so it feels like something's broken

![image](/uploads/a38d7a24d852f1ca95c79426a398b715/image.png)

Story points: 1.0
open sendwyre new tab

<!---
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

(Summarize the bug encountered concisely)

### Steps to reproduce

(How one can reproduce the issue - this is very important)

### Platform information 

(Browser, device, system stats, screen size)

### What is the current *bug* behavior?

(What actually happens)

### What is the expected *correct* behavior?

(What you should see instead)

### Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's very hard to read otherwise.)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 1.0
Localization Page should link to translate.minds.com

<!---
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

Localization page still contains a link to poeditor.com.

Localization page is accessible via links within the following pages:
* /canary
* /mobile
* /content-policy
* /jobs
* /token
* /pay
* /upgrades
* /plus
* /pro
* /nodes
* /boost
* /rewards
* /youtube-migration
* /branding
* /p/terms
* /p/privacy
* /p/contact
* /p/dmca
* /p/billofrights

### What is the expected *correct* behavior?

POEdit link (as provided within the localization page) should be replaced with  a link to the updated Crowdin URL.

### Relevant logs and/or screenshots

* Localization Page<br>
https://www.minds.com/localization

* POEdit Facility<br>
https://poeditor.com/join/project/A45VLCwD0Y

* Crowdin Facility<br>
https://translate.minds.com

Story points: 1.0
Updates to ban email

1) Make Content Policy a hyperlink to https://minds.com/content-policy

2) Add specific reason they were banned. Update text to read:

"Unfortunately, your channel has been banned for violating our Content Policy. The specific reason is (insert reason)." 

3) Remove section about downloading the mobile app because they were banned

![Screen_Shot_2020-07-29_at_1.30.05_PM](/uploads/82c0df9adc70077351f83e1e4a96dbd8/Screen_Shot_2020-07-29_at_1.30.05_PM.png)

Story points: 1.0
Pressing "unlock" on Minds+ post should trigger Minds+ upgrade modal

<!---
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 when you press unlock on a Minds+ post it opens the regular Pay modal. It should open the Minds+ modal. Also the image for the Minds+ modal is not rendering. Screenshots attached.

### Steps to reproduce

1. Go to https://minds.com/raymundo from Minds+ enabled test channel
2. Click unlock


### Platform information 

Chrome, Macbook 

### What is the current *bug* behavior?

See summary

### What is the expected *correct* behavior?

Trigger Upgrade to Minds+ modal

### Relevant logs and/or screenshots

![Screen_Shot_2020-07-21_at_11.23.13_AM](/uploads/30b4ef2bfb40de32ab50e746a967b58e/Screen_Shot_2020-07-21_at_11.23.13_AM.png)

![Screen_Shot_2020-07-21_at_11.23.22_AM](/uploads/23912608775baab821b4a09bf08de9ce/Screen_Shot_2020-07-21_at_11.23.22_AM.png)

![Screen_Shot_2020-07-21_at_11.23.26_AM](/uploads/2739cb23d1edd78601c375536d3b0fd6/Screen_Shot_2020-07-21_at_11.23.26_AM.png)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 1.0
Pro sites flashes Minds sidebar navigation before loading

<!---
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

Pro sites flashes Minds sidebar navigation before loading

### Steps to reproduce

- go to timcastirl.minds.com

### Platform information 

Mobile

### What is the current *bug* behavior?

Sidebar navigation opens

### What is the expected *correct* behavior?

Shouldn't display

### Relevant logs and/or screenshots

![Screenshot_20200712-041044_Firefox](/uploads/4551b3bee8403a87201365ed693ea20a/Screenshot_20200712-041044_Firefox.jpg)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 1.0
Persistent Feed: "View comments" under activity post

<!---
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
--->

In Persistent Feeds #5698, we removed the comments-outlet in the feed and with it we removed the "View comments" link. We now want to add it back

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Re-Add the "View comments" link under the activity posts in the feed.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

Make sure "View comments" is visible under posts that have comment

## 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

## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->

Same exp as persistent feed

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] "View comments" is visible

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Regression: Comments not working on Staging

### Summary

Tapping on Comments button is not opening Comments. 

### Steps to reproduce

1. Open minds staging
2. Navigate to a channel
3. Tap on comments icon within a post
4. Nothing happens

### Platform information 

Chrome - Staging

### What is the current *bug* behavior?

Tapping on Comments does nothing

### What is the expected *correct* behavior?

Tapping on Comments should load comments

### Relevant logs and/or screenshots

![CommentsNotWorking](/uploads/91f70f1e78bc6413436cbac09b20551e/CommentsNotWorking.mov)

Story points: 0.0
Clearly communicate refund policy on payment screens

<!---
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
--->

Clearly communicate refund policy on payment screens so that we are not at risk of losing any disputes on chargebacks and so that the user understands that there are no refunds.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

On all screens where users are able to submit a payment, add a check box for them to agree that there are no refunds.


## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

- Payments cannot be sent unless box is checked that user understands refund policy


## UX/Design

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

- No design necessary, developers can handle
- Superminds - "I understand this transaction is non-refundable once the recipient approves my offer"
- Memberships - "I understand this transaction is non-refundable"
- Tips - "I understand this transaction is non-refundable"
- Minds+ - "I understand this transaction is non-refundable"
- Minds Pro - "I understand this transaction is non-refundable"


## Personas

<!---
Who does this user impact and why (optional)
--->

- Customers are better informed on our refund policy
- Minds admins are better able to respond to chargeback disputes


## Experiments

<!---
Experiments are not required, but it should be made clear if one is expected. If experiments are required, the hypothesis should be outlined.
--->

- None


## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Superminds cannot be sent unless this box is checked
- [ ] Tips cannot be sent unless this box is checked
- [ ] Minds+ cannot be purchased unless this box is checked
- [ ] Minds Pro cannot be purchased unless this box is checked
- [ ] Memberships cannot be purchased unless this box is checked

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Confirm price & authorization after pressing post, before creating Supermind offer

## Goal

Clearly communicate to a use creating a Supermind offer the amount of their offer before they commit to authorizing the charge, in order to avoid mistakes.

## What needs to be done

* [ ] On composer, when pressing Post, ensure there is a confirm modal outlining price and authorization on card
* [ ] User must fill a checkbox to confirm they agree to terms.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

- [Figma mock](https://www.figma.com/file/thrGepQAxmcMGB7MoEEckM/Supermind?node-id=1562%3A19944)

## 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

- [ ] On composer, when pressing Post, ensure there is a confirm modal outlining price and authorization on card
- [ ] User must accept terms before the "Confirm" button is active
- [ ] Playright test

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Web Automation: Remove cypress tests from gitlab pipeline

<!---
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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Remov

Story points: 1.0
Reposition permalink for paywalled single activity 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

<!---
Clearly outline the goal of the issue and why we are doing it
--->
Move the permalink to the bottom
With activity v2 enabled, see www.minds.com/newsfeed/1411707490558545940

![image](/uploads/eedb7b36aebebdfb2973ba80836fa6e1/image.png)


## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
For paywalled single activity pages, move the permalink to the bottom

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
The permalink should be at the bottom of the post, not in the middle of the paywall

## 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)
--->
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.
--->
none

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] permalink at bottom of post

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Minimal mode cleanup for paywalled and quote posts

<!---
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
--->
Minimal mode posts (e.g. the ones in suggested sidebar posts and pro galleries) need some attention. The paywall badges cover up content sometimes and the new activity hover feature looks a bit weird sometimes (e.g. when you are hovering over a quote post there is weird spacing above the date).

<details><summary>📸 See images</summary>
![image](/uploads/2450433a38a27c8cb528cb4b4bccd051/image.png)
![image](/uploads/7380d5508801ebc950f25b8e46eec962/image.png)
![image](/uploads/01b9825e3c3da390cd90a0e1c8a6e74f/image.png)
</details>



## 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
--->
Look at a lot of sidebar suggestion posts in a variety of activity/content types.

## 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)
--->
users who view single activity pages

## 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
--->

For 'minimal mode' posts:
- [ ] content is completely visible (e.g. not covered by paywall badges)
- [ ] hover highlight is intuitive and has natural looking spacing


Post types include: 
- images
- vids
- status posts
- rich-embed/blogs
- reminds
- quotes with deleted sources
- nsfw posts
- quotes (incl. quotes of the types listed above)

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Suggested sidebar posts in group context should have owner blocks

<!---
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
--->
Show owner blocks for suggested sidebar posts when in a group context.  Right now the posts are showing but we don't know who made them.

![image](/uploads/729b23812b4360d4ba26f27ac5a6d903/image.png)

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Enable show owner block in the group single page activity sidebar posts

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
In a normal single page post (not in a group), the owner block should remain invisible

## 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)
--->
Group 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
--->

- [ ] owner blocks in sidebar suggestions for group single page posts

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0