giseldo/neodataset huggingface dataset:
Remove "Pending transfers" from wallet

<!---
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
--->

Increase comprehension of the wallet by removing the "Pending transfers" number from the Cash tab. It's confusing and not helping.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

Remove the Pending transfers section from the cash tab of the wallet.

![image](/uploads/0e1b9a8c001052204d8cfcc943a14948/image.png)

## 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?
--->

- [x] 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
--->

- [ ] The pending transfers column is removed from Cash wallets

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Crash when scrolling a channel



### Summary

App crash when scrolling a channel's feed

### Steps to reproduce

Open a channel and try to scroll

### Platform information 

both

### What is the current *bug* behavior?

It crash

### What is the expected *correct* behavior?

It shouldn't crash

### Relevant logs and/or screenshots

![imagen](/uploads/cde97a77ad18eff64488171d569f8e7e/imagen.png)

### Possible fixes

Possible regression

Story points: 1.0
No Method Of Deleting Credit / Debit Card Details For Minds+, Minds Pro & Channel Based Membership Tier Facilities Within Mobile Application

<!---
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
There is a option to delete credit / debit card information within the browser interface's payment / payment methods settings section but this option is not avaible within the mobile application.

### Platform information 
Reviewed using the Android mobile application (version 4.33.0).

### Relevant logs and/or screenshots
![issue_mobile-native_4869-a](/uploads/e2d88344ddc3431b167224649d782aa8/issue_mobile-native_4869-a.png)<br>
<i>Browser interface payment / payment methods settings section example.</i>

![issue_mobile-native_4869-b](/uploads/308585517ab29479d456f665a9efb801/issue_mobile-native_4869-b.png)<br>
<i>Mobile application  payment / payment methods settings section example.</i><br><br>

<b>Reference:</b>
* Browser Interface Payment / Payment Methods Settings<br>
https://www.minds.com/settings/payments/payment-methods

Story points: 3.0
Mob: Channel & Group suggestions 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

<!---
Clearly outline the goal of the issue and why we are doing it
--->

Increase the % of newly registered users who subscribe to channels and join groups in their first session, to improve short term user retention.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

- Interest tag selection is not skippable -- user must select at least 3 interests before proceeding.
- Add Channel and Group suggestions in new user onboarding flow, after user interest tag selection.
- Channel & Group suggestions are influenced by tag selections.
- Channel & Group suggestions ARE skippable.

Deploy as an experiment.

- Control: Tag selection is not skippable, but Channel & Group suggestions are not presented during onboarding.
- Variant: Tag selection is not skippable, and Channel & Group suggestions are presented afterward.

Measure for:

- Channel subscriptions
- Group joins
- User returned after 48 hours

## 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.
--->



![mob-variant-actual-final](/uploads/96c606e1a021bf0e051c8cd101de19d4/mob-variant-actual-final.mov)

[Figma](https://www.figma.com/file/KIrgbpzbogAlPq8Ln1qDHF/NUX-Research-and-UX?node-id=168-20021)


## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [x] 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.
--->

Metrics to watch 
- Number of subscribers per user 
- We hypothesized that since number of subscribers positively correlates to retention for the data we've seen, that if a user subscribes to a greater number of channels / is served more relevant content, they are more likely to retain and stay on the platform.
- 2-3 day retention (user signs up, uses Minds, closes app, rejoins, logs back in and uses within window)

- variant vs. control (existing design)

## 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

UXD:

Story points: 8.0
Mob: Create Boost flow from Boost console

<!---
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

Enable users to create Boosts (channel + activity Boosts) from the Boost console so that more Boosts can be made.

## What needs to be done

Enable a user to create a Boost from the Boost console.

- Channel Boost (can use existing "Boost channel" modal)
- Activity Boost (can use new "Boost latest post" flow)

## 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.
--->

[Figma](https://www.figma.com/file/W2xIag64EdbWUlGAQOpVHE/Boost-Update?node-id=1289%3A23979&t=4NEzNgVJFOP9qobH-1)

![Boost_Post_From_Console](/uploads/e43beedc0ce9a2dd7a1aff7e6e2cb53b/Boost_Post_From_Console.png)

![Boost_Channel_From_Console](/uploads/b3813adf74e0dc592d2bdae25b59eb68/Boost_Channel_From_Console.png)

## 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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Mob: Hide suspected spam comments

<!---
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

Reduce impact of spam by hiding comments that are suspected of spam.

## What needs to be done

We can automatically identify that comments are spam with a high degree of accuracy, but still want human review before they're removed from the site. When a comment is automatically identified as spam -- but before human review -- we should hide the comments from view, and enable the community to show the comments and give feedback about whether or not the automatic spam detection was accurate.

[We got some feedback from the community about a feature like this here](https://www.minds.com/newsfeed/1437588985613389832).

## 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.
--->



![spam-desktop-flow](/uploads/0d494a05e0ca7677f30b36c62c31aba4/spam-desktop-flow.png)

![spam-mobile-flow](/uploads/3f9db355b4f97ef5692d20cab663ba3c/spam-mobile-flow.png)


## Mobile

<!---
Does a mobile card need to be created? Any notes for mobile?
--->

- [ ] Is Mobile Required?

## User testing

<!---
Who does this user impact and why (optional)
--->

- Link to draft -> https://www.notion.so/chints98/Minds-spam-comments-userbrain-test-draft-e4c52c7020ce4e499f4a48c578bf7532?pvs=4

## 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

UXD:

Story points: 8.0
Connect IAP for subscriptions to the backend



## Goal

Connect the IAP to the backend 

https://gitlab.com/minds/engine/-/merge_requests/1290#testing-considerations


## What needs to be done

When the purchase process is finished correctly, call the backend to enable pro/plus
POST /api/v3/payments/iap/subscription/acknowledge

## Acceptance Criteria

- [ ] It should call the backend informing the subscription
- [ ] It should enable pro/plus for the user

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Remove browser links to Pro and Plus from Settings/Resources

<!---
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

- Remove browser links to Pro and Plus upgrades following Google warning re violation of Payments Policy.

<!---
Clearly outline the goal of the issue and why we are doing it
--->


## What needs to be done

o Hide behind the FF for Google Play android version the following items in Resources:
- Plus
- Upgrade
- Pro

o Bump the android version to 4.34.0

o Create v4.34.0 tag

<!---
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
--->
- make sure the build is for Google Play and the FF `mob-4836-iap-no-cash` is turned on (default is off).
- check if links were removed.

## 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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Vertical videos can be aligned better without the black boundary

## Goal

Vertical videos should appear vertical instead of adding black background on right and left of the video.

Reported by Bill.


## What needs to be done

Fix alignment of vertical videos. Happens when taking video from the gallery. Happens on both android and iOS.

https://www.minds.com/newsfeed/1487467449308680197

![11416682-B13D-4463-8810-6EA8FC39DE43](/uploads/7892675407c5b2c2bf54aab3c3bf9308/11416682-B13D-4463-8810-6EA8FC39DE43.png)


## 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?
--->

- [x] 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
--->

- [ ] Video should not have black boundary when uploading.

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Comments view get truncated when typing


### Summary

Comment view is getting cut off when typing on certain android devices.

Reported by Bill. Cannot reproduce on my iOS.

### Steps to reproduce

1. Navigate to a post.
2. Enter a multiline comment. 

### Platform information 

Bill’s android device

### What is the current *bug* behavior?

Comment view when typing does not show multilines. 

### What is the expected *correct* behavior?

Comment view should show multiple lines as expected

### Relevant logs and/or screenshots

![F1C0D633-8EB8-45B8-9161-33A7B6EFFD71](/uploads/031fe717f3d32f77b680ab30ab7e4b72/F1C0D633-8EB8-45B8-9161-33A7B6EFFD71.png)

Story points: 3.0
Scheduling posts gets an error

<!---
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

Trying to schedule a post, crashes the app (fullscreen error)

### Steps to reproduce

1. Open the composer
2. Click cobwheel > Schedule
3. Click custom time
4. See you get error



### Platform information 

Happens consistently on iOS, didnt test android

### What is the current *bug* behavior?

Getting error

### What is the expected *correct* behavior?

No error

### Relevant logs and/or screenshots

Unexpected error occurred

Error: Fatal: TypeError Cannot read property 'clone' of undefined

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 2.0
Store release - 4.33.0 - Android Only

<!---
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
--->
Store release - v4.33.0


## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Run a smoke test and review all already tested tasks from staging environment.

#4853
#4810
#4807
#4850

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->
- store release only for Android

## 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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 1.0
Hide Boosts and Subscriptions behind a Feature Flag to pass Google issue

<!---
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

- Temporary hide the Minds+ and Boosts behind the `mob-4836-iap-no-cash` and republish the app in Google Play

<!---
Clearly outline the goal of the issue and why we are doing it
--->


## What needs to be done
- hide the Minds+ and Boosts behind the `mob-4836-iap-no-cash` 
- bump store version
- republish the app in Google Play

<!---
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
--->

Need to get the newly built apk.
Enable flag and verify that Minds+ and Boosts show no cash options.

## 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
--->

- [ ] ...

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Hide

Story points: 3.0
Referrals link is invisible on dark / light mode (Mobile)

<!---
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)

If a user uses dark mode on mobile, and tries to access the referrals link, they can go to the current referrals page. However, the referral link text is currently invisible. (referral link text is same as background color.)

The problem manifest only when switching from one mode to another. The color of default text do not update correctly.


### Steps to reproduce

(How one can reproduce the issue - this is very important)

Step 1: On mobile app, switch to dark mode. 
Step 2: Go on sidebar navigation menu, and access settings page. 
Step 3: Go from the settings page to other -> click on referrals page.
Step 4: On referrals page, view referral links, and you will notice that the css-color of the link is not being changed between light and dark mode.

Note- sometimes this flips, so that light mode is legible, but dark mode is not. See below. 

![image](/uploads/0b59e39aaf6efa209d68f56f2736cc5e/image.png)

### Platform information 

(Browser, device, system stats, screen size)
- Mobile apps (React Native, iOS, Android)

### What is the current *bug* behavior?

(What actually happens)

![image](/uploads/2be937712b6679f69d2666ed92cabcb9/image.png)

![image](/uploads/a632ed26beed6cff6e3e12f0297d080d/image.png)

### What is the expected *correct* behavior?

- expected behavior should be white text in dark mode, primary text in light mode.


(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
Boosts not appearing on mobile app

<!---
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

Boosts are not appearing on the Newsfeed in the iOS app in the Top posts. Boosts are ok on latest.

### Steps to reproduce

- Navigate to the Newsfeed and scroll

### Platform information 

- iOS app (3x phones)

![image](/uploads/5e07c67702d11935bbd6c5907700d37c/image.png)

### What is the current *bug* behavior?

- No Boosts appear

### What is the expected *correct* behavior?

- Boosts appear every 6x posts

### Relevant logs and/or screenshots

n/a

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 3.0
Implement the boost channel in-feed notice on mobile



## Goal

Add the `boost-channel` in-feed notice on mobile

Related to https://gitlab.com/minds/minds/-/issues/3640

## What needs to be done

Implement the in-feed notice and ensure that is added to the in-feed notices mapper

## QA

Check that the notice is shown 

## UX/Design

![imagen](/uploads/c0aa73dd90c55d594e288741bc2fadd4/imagen.png)

## Acceptance Criteria

- [ ] The notice should be shown when the backend indicates

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Imnpl

Story points: 2.0