giseldo/neodataset huggingface dataset:
Last accessed field for all sessions is incorrect

### Summary

Last accessed field is incorrect for all sessions displayed. Works correctly on Web. 

### Steps to reproduce

1. Open mobile app.
2. Navigate to settings -> security.
3. Tap on Your Devices.
4. Notice that all sessions have the same timestamp which is the current timestamp. This is not possible and does not match web values. 

### Platform information 

iPhone 13 Pro

### What is the current *bug* behavior?

Last accessed field value is incorrect. 

### What is the expected *correct* behavior?

Last accessed field value should be accurate. 

### Relevant logs and/or screenshots

![74D20A64-53C1-487B-8F75-5209A26903DF](/uploads/04b0855635bb9a7cd968b3b49ccda4dd/74D20A64-53C1-487B-8F75-5209A26903DF.jpeg)

Story points: 2.0
Boost v3 remove use tokens modal

<!---
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 UX friction

## What needs to be done

Remove are you sure you want to use tokens modal when switching between budget panels in boost v3 modal

## QA

Modal should not appear - switching between pools should function correctly. E2E should pass.

## UX/Design

N/A

## Personas

Boosting users.

## Experiments

Covered by larger boost v3 flag - no need to touch for this individual change.

## Acceptance Criteria

- [ ] Keep the component (as we may bring it back), but remove the execution of the popup confirmation modal on switch to token budget selection panel
- [ ] Ensure E2E and unit pass (This WILL LIKELY break E2E)

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 2.0
Add Boost-related context to 'action' events

<!---
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

- As Minds, I want to know what is the engagement rate of Boosted posts in various positions in the app so that I can optimize the performance of Boosts.
- As a Boost user, I want to know what engagements on my post are attributable to a Boost, so that I can evaluate the ROI for Boosting.

## What needs to be done

Add context to engagement events (upvotes, downvotes, reminds, comments) that enables us to discern these engagements from organic appearances and Boosted appearances.

Possibly: Use existing Boost campaign `event_props`, `view_campaign`, and/or `view_medium` attributes.

Possibly need to add a context for boosts or just marked the events with is_a_boost flag.

## 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

- [x] Mobile ticket required?

Mobile will need to send the context with the events such as 'votes'.

## 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
--->

- [ ] Action events should include the context of the entity

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 8.0
Full screen videos only allow portrait mode on Android



### Summary

When playing a video in full screen it doesn't allow to rotate the screen

### Steps to reproduce

Play a video in full screen on an android device

### Platform information 

Android

### What is the current *bug* behavior?

When playing a video in full screen it doesn't allow to rotate the screen

### What is the expected *correct* behavior?

Landscape mode should be allowed (like iOS)

### Relevant logs and/or screenshots

-

### Possible fixes

TBD

Story points: 3.0
Automate Changelog Generation

<!---
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

In order to avoid merge conflict headaches resulting from manually updating the CHANGELOG.md, we can leverage [Gitlab changelog entries](https://docs.gitlab.com/ee/development/changelog.html) and have the changelog updates as part of the CI.

https://github.com/jimmidyson/gitlab-ce/blob/master/doc/development/changelog.md#history-and-reasoning

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

- document usage of `Changelog` git trailer
- add the generate_changelog to the pipeline and only run on master
- make sure the commit to update the changelog doesn't run all pipelines. Add a `[skip ci]` or similar keyword in the commit message and prevent pipelines running for that commit 


## 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.
--->

None 

## Personas

<!---
Who does this user impact and why (optional)
--->

Devs and QA

## 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
--->

- [ ] changelogs are automatically handled by gitlab

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Setup channel in feed notice not shown on mobile



### Summary

The setup channel in-feed notice is not shown on mobile

### Steps to reproduce

- With a new user complete the social compass
- The setup channel should be shown the next time

### Platform information 

both

### What is the current *bug* behavior?

It is not showing the notice when the backend says that it should

### What is the expected *correct* behavior?

it should show it

### Relevant logs and/or screenshots

-

### Possible fixes

Fix the name of the in feed notice

Story points: 1.0
in-app verification prompt is always shown if the FF is enabled



### Summary

The verification prompt is always shown if the feature flag is on

### Steps to reproduce

enable FF

### Platform information 

both

### What is the current *bug* behavior?

it is always shown

### What is the expected *correct* behavior?

It should be shown only when the verify uniqueness is going to be shown

### Relevant logs and/or screenshots

-

### Possible fixes

Move the render to the verify uniqueness in feed notice

Story points: 2.0
Add Performance Monitoring to App

<!---
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

Improve app's performance by constantly monitoring the render and navigation transition times.

## What needs to be done

Add Shopify's performance monitoring libs and hook them in the app.

## QA

App should perform with unnoticed differences.

## 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)
--->
Developers

## 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: 8.0
Record 'view' events on InFeed notices

<!---
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
--->
Gain insights into the effectiveness of the feed notices by tracking their visibility 

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Use the new 'generic' events to trigger a 'view' when the in feed notice is displayed

## 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

## 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.
--->
N/A

## Acceptance Criteria

<!--
Everyone should be able to understand what is expected to be delivered
--->

- [ ] Generic view even is recorded when in feed notices are displayed
- [ ] Each in feed notice has an appropriate reference

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Clarify expectations with Twitter connection for Supermind

<!---
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

As a user responding to a Supermind, I want to know why Minds is requesting permission to post on my behalf and know that nothing is being posted just by connecting w/ Twitter oauth.

As a user responding to a Supermind, I want to visualize what will be posted to Twitter before agreeing to it.

## What needs to be done

Spec improvements to the UX of flows related to posting Superminds to Twitter to address the user stories above.

- Flow 1: Connecting to Twitter oauth before responding to a Supermind offer that requires Twitter repost. (Happens once for a user.)
- Flow 2: Reposting a Supermind respond to Twitter. (Can happen multiple times for a user.)


## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

https://gitlab.com/minds/minds/-/issues/3602

<!---
Sufficient wireframes have been presented and understood by the development team. Full mockups are not required and re-usable components are encouraged.
--->

See https://gitlab.com/minds/minds/-/issues/3602

## Personas

<!---
Who does this user impact and why (optional)
--->

Creators

## 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
--->

- [ ] Implement the design changes in https://gitlab.com/minds/minds/-/issues/3602
- [ ] Update E2E tests

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Boost offer in-feed notice: onPress causes the More tab to be inaccessible

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

The onPress of the boost offer in-feed notice causes the More tab to be inaccessible.

### Steps to reproduce

- Press the onPress on the boost offer in-feed notice.
- try to access the More tab

### Platform information 

(Browser, device, system stats, screen size)

### What is the current *bug* behavior?

The More tab will be inaccessible 

### What is the expected *correct* behavior?

The More tab should be accessible and the boost console should be pushed in the More stack

### 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.)

N/A

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 3.0
Doubletapping thumbnail of a link produces white screen 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

Doubletapping thumbnail of a link produces white screen error

### Steps to reproduce

1. Go to the app
2. Find a post with a link that contains a thumbnail
3. Doubleclick that thumbnail, like you want to zoom in on that image
4. See that you may get the white screen error

### Platform information 

iPhone XR

### What is the current *bug* behavior?

Error on link doubletap

### What is the expected *correct* behavior?

There should be no error on doubletap

### Relevant logs and/or screenshots

https://www.minds.com/newsfeed/1458092455172771847

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 3.0
Intl pluralization polyfill needed and use user chossen language with i18next


### Summary
 1. The i18next package is throwing an error due to the lack of Intl pluralization support.
 2. The new i18next implementation is not using the user's language (it is "disconnected" of the current language support)


### Steps to reproduce

1. Missing Intl error shown on the console
2. Changing languages doesn't affect new i18n implementation


### Platform information 
both

Story points: 2.0
Update expo SDK to 47 & react-native to 0.70



## Goal

Update the expo SDK to 47 and react-native to 0.70

This will update the video player and all the expo packages. It will also allow us to start testing expo-image

## What needs to be done

- Update expo SDK
- Update react native

## QA
- 

## UX/Design

-


## Personas

-


## Experiments
-


## Acceptance Criteria

- [ ] Expo and RN should be on the latest version
- [ ] The app should work properly

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Update

Story points: 5.0
Boost Composer: estimated reach and slider steps

<!---
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
--->

Add the Estimated reach field to the boost composer and add steps to the slider

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->

"Estimated reach" should be available in the boost composer replacing "Unknown"

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->

Make sure Estimated reach is shown when creating a boost

## 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)
--->

Boosters

## 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
--->

- [ ] Estimated reach is shown when creating a boost

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
"See latest" UX issue

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "T - Bug" label and verify the issue you're about to submit isn't a duplicate.
--->

### Summary

The see latest prompt positioning is awkward and it sometimes blocks content underneath it without being dismissible. These issues should be resolved.

### 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?

- positioning of the "see latest" prompt is wrong
- it is not dismissible

### What is the expected *correct* behavior?

- position of the prompt should be near the top of the newsfeed
- it should be dismissible, either manual, automatic, or both (with timeout).

### Relevant logs and/or screenshots

![image](/uploads/03803ab8472ac4251afdb9169076ab02/image.png)

### Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Story points: 3.0
Add E2E integration tests to 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
--->
Add E2E integration tests to pipeline

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
- add E2E integration tests to pipeline after a merge to master.
- 

## 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

## Personas

<!---
Who does this user impact and why (optional)
--->
Developers

## 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
--->

- [ ] Visible in pipeline

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

A

Story points: 3.0
Add Boost option to all posts

## Goal

- Enable more boosting opportunities. (Increase boosts.)
- Enable Minds team to promote good content.

## What needs to be done

Currently, the option to boost a post appears only on posts that you own.

For this change, we want to add the option to boost from any post.

## QA

<!---
Consideration is given to how the issue will be demoed and tested prior to being deployed
--->


## UX/Design

See acceptance criteria

## Personas

- Minds staff

## Experiments

n/a

## Acceptance Criteria

- [ ] The option to boost posts appears on all activity posts, not just ones yours.
- [ ] The option should appear in the dropdown menu if it is not your post

## Definition of Ready Checklist

- [ ] Definition Of Done (DoD)
- [ ] Acceptance criteria
- [ ] Weighted
- [ ] QA
- [ ] UX/Design
- [ ] Personas
- [ ] Experiments

Story points: 3.0
Add max width for the screens for iPad and tablets

<!---
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
--->
Improve the UI/UX of the app on iPad and tablets.

## What needs to be done

<!---
Clearly detail what needs to be done to achieve the goal set out above
--->
Add max-width to all screens for iPad and tablets to 690px.

## 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

Story points: 2.0
Location detection is very slow on iOS



### Summary

Expo Location is very slow on iOS (Many seconds)

This delay the in-app verification flow

Related to #4692

### Steps to reproduce

Get location on iOS

### Platform information 

iOS

### What is the current *bug* behavior?

It takes many seconds to get the position

### What is the expected *correct* behavior?

it should work in less than 2 seconds

### Relevant logs and/or screenshots

-

### Possible fixes

TBD

Story points: 2.0