giseldo/neodataset huggingface dataset:
Moderation queue number incorrect & posts duplicating.

<!---
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

If you are a moderator of a closed group, when you've approved all of the posts, you will likely see one or two still remaining, that you are unable to approve, as they are not in the queue. You will also see that some posts that you have already approved, are duplicate in the feed, one approved entity, one unapproved, with nothing in the moderation queue.

### Steps to reproduce

Requires that you are a group moderator of a closed group.

### Platform information 

Cross-platform web

### What is the current *bug* behavior?

Queue will show posts awaiting approval that are not

### What is the expected *correct* behavior?

Queue should show empty if there are no posts to approve, furthermore posts should not be getting duplicated.

### Relevant logs and/or screenshots

Video at this link
https://www.minds.com/newsfeed/999958056778829824

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 1.0
(bug) gathering-heatbeat markers arrive at the client with an unsafe integer value for user_guid

gathering-heartbeat markers are received with unsafe integer values where guid entities are sent as strings
```json
{
  "user_guid":994952798468575247,
  "entity_type":"group",
  "entity_guid":"997822291385520137",
  "marker":"gathering-heartbeat",
  "updated_timestamp":1563367071,
  "disabled":false,
  "read_timestamp":null
}
```

This gives unexpected results if the value is use in Javascript

Story points: 1.0
(chore) refactor activity links into a Propagate action

We're doing a lot of this.

https://gitlab.com/minds/engine/blob/master/Core/Feeds/Firehose/Manager.php#L106

`foreach ($this->db->getRow('activity:entitylink:'.$entity->getGUID()) as $parentGuid => $ts) {`

Because blogs contain links to activities when they get published. Images and videos contain multiple links to activities (one image to many activities).  Yet, we have properties like NSFW, NSFW_LOCK, allow_comments ... etc that need to be propagated up and down the chain

So, when an owner or admin changes a property that applies to parents or their children, we need to create an action that applies those changes up and down the chain.

There's a question of source of truth. If there is a collision between a flag, who should win - the parent object or the object receiving the change?

Part of this card will be figuring out what flags need to be set and how they should be propagated.

Ideally, @markeharding wants them all to be activities with the attachments just inheriting the activities permissions, so we might want to take the opportunity to bring all our entities under the same banner. The activity has the permissions, the images, videos and blogs would just inherit their parent's permissions.

Looping in @markeharding @edgebal and @gthouret for their thoughts on how to roll this out.

Story points: 10.0
Backend for accepting subscription requests

Create an api for requesting subscriptions to a channel
---------

**GET** `/api/v2/subscriptions/incoming`
> Gets a list of all pending subscription requests 

**PUT** `/api/v2/subscriptions/outgoing/{{channel_guid}}`
> Creates a new subscription request for a user
> Sends out a push notification to the channel owner that a new subscription request has been created

**DELETE** `/api/v2/subscriptions/outgoing/{{channel_guid}}`
> Deletes a subscription request made

**PUT** `/api/v2/subscriptions/incoming/{{channel_guid}}/accept`
> Accepts a new subscription request for a user, assigns them the subscriber role for that channel guid

**PUT** `/api/v2/subscriptions/incoming/{{channel_guid}}/decline`
> Denies a new subscription request

Story points: 3.0
(feature) Limit the feeds for channels to subscribers only

When a user marks their channel as closed, we must update the feeds to only show to subscribers.

All posts in the feed will need to be marked with open and closed
Changing a channel's open or closed endpoint will need to reindex the channel
When a user requests a channel, we will need to provide a list of all channels they are subscribed too
We will need to exclude any entity which belongs to a closed channel that they do not subscribe too

Story points: 15.0
(feat) Implement delete flag with the new permissions scheme

Since our delete permissions are combined with editing permissions, this is an excellent place to start and role out the new RBAC permissions scheme.

Wherever we check for delete permissions, use the new role based stuff to calculate. When we look up an entitie's ownership, use RBAC to assign owner permissions. This will only have to get overridden by the admin roles and the group ownership roles

Story points: 5.0
(feat) Implement Zend RBAC framework for managing role based permissions

In the Permissions Module, create a Roles namespace

Create roles for:
Admin
Moderator (user community folks with moderation privileges)
Owner (can own channels, groups or entities)
Subscriber (can subscribe to groups or channels)
Blacklisted (cannot see or interact with content)
Viewer (default permissions)

Track entity to role relationships
Admins are global, they have full permissions
Moderators are global, but they have limited permissions
Owners are associated to channels, groups or entities and have administrative privileges over things they own
Subscribers get permissions controlled by the owner


Permissions that can be assigned by roles (will grow over time)
canView
canDelete
canComment
canTag
canEdit
canBlacklist
canBlock  

TBD: flesh out individual permissions

Create admin endpoints under
/api/v2/permissions/users/{user guid}
GET Gets the user's permissions object, all roles, subscriptions,

Story points: 20.0
(bug): User images missing

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

https://www.minds.com/newsfeed/994094451015606272
A users images are not appearing correctly on the sidebar on a users profile, and in the images.

### Steps to reproduce

1. Visit https://www.minds.com/QuiteJane
2. Look at images (there should be many)

Note that the first time I did this, I could see all of her images fine. After going back and forth a few times, all dispeared.

### Platform information 

Cross platform on web only. (tested Android S7 edge on v3.7.2)

### What is the current *bug* behavior?

The images are not there.

### What is the expected *correct* behavior?

Her images should be visible.

### Relevant logs and/or screenshots

# The first attempt:
![Wire_2019-07-07_at_8_12_PM](/uploads/71427692997e7835a21bcd167c76d37e/Wire_2019-07-07_at_8_12_PM.png)

# After clicking around, they disappeared.

![image](/uploads/84c647561cf2e33137049d95e5b2859c/image.png)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 5.0
(bug): 500 error on editing blog activities text in newsfeed

<!---
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

Changes to the activity of a blog are not saving. Checking the dev tools reveals a 500 error is at fault.

### Steps to reproduce

1. Post a blog.
2. Try to edit the test on your wall.

### Platform information 

Reproduced Chromium / Manjaro

### What is the current *bug* behavior?

Changes do not save.

### What is the expected *correct* behavior?

Changes should save.

### Relevant logs and/or screenshots

![image](/uploads/48eaf465267a64a62760ff98a9af39ac/image.png))

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 1.0
(feat): Offchain 3 pending boost limit.

Pending merge of https://gitlab.com/minds/engine/merge_requests/251 to avoid conflict

Chats with @IanCrossland and @javanick suggested that we put a pending boost limit of 3 boosts, to stop users spamming the queue with 1 token boosts, and also so that people cannot attempt to spam the network to gain overall control over the content being displayed.

Story points: 5.0
SPIKE: Use Vitess for storing Votes

<!---
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
--->
Bringing comments to Vitess enables easier querying of a users social graph, it also helps us not show the same content in recommendations

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Create a prototype of storing votes in Vitess


## 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

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## 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.
--->
For feature flag

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Store votes in Vitess
- [ ] Query votes from Vitess, fallback to Cassandra for source of truth
- [ ] Migrating existing votes are out of scope

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 5.0
Only export paywalled preview text when paywall context experiment is on

<!---
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
--->
In https://gitlab.com/minds/engine/-/merge_requests/1289, we brought back 'teaser' text for paywalled media posts, which had been broken as a result of an unrelated bug. We made this change so that we can experiment with whether displaying a small amount of preview text increases Minds+ subscriptions https://gitlab.com/minds/minds/-/issues/3857. Because it _used_ to work, we implemented the backend change universally (e.g. NOT only for users in the experiment) and failed to consider how the teaser text would be displayed for users outside of the experiment. 

Currently, for users who are not in the experiment, we are only enabling 'read more' when the post's char count is > 280, but only 200 chars are exported for the teaser text. If the user isn't in the experiment, this results in teaser text looking like it just stops in the middle of a sentence, without a graceful transition (such as '...'). 

As seen in /newsfeed/1485362836300369927: 
![image](/uploads/9192f58341a56c36d5c858e55ef392f0/image.png)

The easiest way to fix this as was originally intended in https://gitlab.com/minds/minds/-/issues/3857 is to "break" the teaser text export again, only for users who are not included in the experiment. 

The change should be made in the `isStatusPost()` function in Core/Wire/Paywall/Events.php 

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
Paywalled media teaser text 

## 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

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## 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.
--->
Relates to 'minds-3857-paywall-context'

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Don't provide any teaser text for paywalled media posts for users outside of experiment 'minds-3857-paywall-context'

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Update Growthbook implementation to ensure stability of variation assignment

## Goal

The value of running experiments in Growthbook comes from being able to reliably infer causal relations from the statistical difference of behaviour between a control group and treatment group. For this to be reliable, the assignment of a given user to a control group or a treatment group should be as stable as possible. There is room improve this stability in the current Growthbook integration.

## What needs to be done

- The first time an SDK call is made to select a user/device into a feature variation (in a logged-out state), save the selected variation to a dedicated local persistent cookie for that feature
- On all subsequent requests for a selection to a given feature (in logged-out state), first check to see whether a variation has been stored in a local persistent cookie. If so, return that value as the selection in the SDK call. If not, run the experiment assignment, and store the value as above

### Dev notes

https://gitlab.com/minds/front/-/blob/master/src/app/modules/experiments/experiments.service.ts#L85


- Store as a JSON object with a single key
- Confirm that it is an experiment before using the cached assignment

## QA

Ensure that for transitions between logged-in and logged-out states, and transitions to different devices and browser sessions that, as much as possible, the assignment of a variation for a given feature is stable for a given user.


## Acceptance Criteria

- [x] Logged-out variation assignments are stable between browser sessions
- [x] Logged-in variation assignments are consistent from session to session
- [x] Logged-out and logged-in assignments are consistent as much as possible
- [x] Rate-limiting of callbacks to Snowplow events, per-feature, are preserved as in the current implementation
- [x] Ensure rate-limiting is as reliable as possible (in both directions: not blocking events that should go, and blocking events that shouldn't go)

## Definition of Ready Checklist

- [x] Definition Of Done (DoD)
- [x] Acceptance criteria
- [ ] Weighted
- [x] QA

Story points: 3.0
Selection of recommendations cluster, post-signup, for newly-registered users

## Goal

Currently, new users, and users without any engagement data are all assigned to a default recommendations cluster.  The ETL pipeline is now providing a mechanism for selecting a cluster based on interest tags selected at signup. This task will make use of that facility when populating the Explore recommendations feed for such users

## What needs to be done

Obtain the list of selected interest tags for the user, place them in the appropriate query, and retrieve the corresponding cluster_id for recommendations. Use this cluster_id to populate the Explore recommendations feed.

## QA

Dev and data manual check of output data against inputs

## Acceptance Criteria

- [ ] New users and users without engagement data have feeds populated based on interest tag selection according to the query provided by the ETL pipeline

## Definition of Ready Checklist

- [x] Definition Of Done (DoD)
- [x] Acceptance criteria
- [ ] Weighted
- [x] QA

Story points: 3.0
Update default tags in onboarding

<!---
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

Increase differentiation in audience interests indicated by interest tags selected during onboarding by updating the default tags presented.

## What needs to be done

Update the default tags presented in the onboarding tag selection modal.

![image](/uploads/5f7fde306a496983c1432214a13d4368/image.png)

| Order | Tag          | Change |
|-------|--------------|--------|
| 1     | technology   | keep   |
| 2     | crypto       | keep   |
| 3     | nature       | keep   |
| 4     | travel       | keep   |
| 5     | outdoors     | keep   |
| 6     | animals      | add    |
| 7     | memes        | keep   |
| 8     | erotica      | add    |
| 9     | news         | keep   |
| 10    | politics     | add    |
| 11    | spirituality | keep   |
| 12    | health       | add    |
| 13    | education    | add    |
| 14    | business     | add    |
| 15    | sports       | keep   |
| 16    | comedy       | keep   |
| 17    | fashion      | keep   |
| 18    | anime        | add    |
| 19    | gaming       | add    |
| 20    | art          | keep   |
| 21    | music        | keep   |
| 22    | photography  | keep   |


[Source](https://docs.google.com/spreadsheets/d/17YrfeEqFy6a7iyHAy0sr9hBQQIZScAwKlJxy4X5PPno/edit#gid=651592439)

OJM - these ones are removed: 
| REMOVE       |
|------------|
| blog      |
| minds      |
| myphoto    |
| videos     |
| journalism |
| blockchain |
| food       |
| nutrition  |
| film       |
| poetry     |

## 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.
--->

## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## 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
--->

- [ ] Changes made as per table above

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Ensure payments are not created and captured when Vitess is down and cannot be written to.

<!---
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

If Vitess is for example in read-only mode, it appears as though payments will be taken but Vitess may not actually create the Boost

### Steps to reproduce

1. Have Vitess in read-only mode
2. Try to make a Boost

### Platform information 

Web

### What is the current *bug* behavior?

Payments are created with no Boost

### What is the expected *correct* behavior?

We need to fix this. We should also make sure that this doesn't happen on admin action.

Ideas:

- Writable state probe before we start the transaction.
- Graceful fallback logic in the event of failure (send tokens or cash back).
- Refactor logic to take payment after Boost creation, perhaps by creating it in a PENDING_PAYMENT state, then either failing or moving to pending based on whether payment is taken.

### Relevant logs and/or screenshots

N/A

### Possible fixes

See above

Story points: 2.0
Cannot post rich embed without content

<!---
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

Cannot post rich embed without content

### Steps to reproduce

1. Post rich embed
2. Remove text
3. Hit post

### Platform information 

Web

### What is the current *bug* behavior?

Cannot post rich embed without content

### What is the expected *correct* behavior?

Should be able to post rich embed without content

### Relevant logs and/or screenshots

Pretty sure the issue was introduced here https://gitlab.com/minds/engine/-/merge_requests/1285/diffs#94ae1be37d4b0d4f24c8dd7cb64dee5e316f6e36_524_530

### Possible fixes

https://gitlab.com/minds/engine/-/merge_requests/1285/diffs#94ae1be37d4b0d4f24c8dd7cb64dee5e316f6e36_524_530

Story points: 2.0
Stripe conf issues for users with no emails

<!---
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

Stripe conf issues for users with no emails

### Steps to reproduce

Try to post with no email

### Platform information 

Web

### What is the current *bug* behavior?

Can't post with no email

### What is the expected *correct* behavior?

Should be able to post 

### Relevant logs and/or screenshots

https://minds-inc.sentry.io/issues/4041441729/?query=is%3Aunresolved+user.id%3A756196975912689669&referrer=issue-stream&statsPeriod=14d&stream_index=5

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 1.0