giseldo/neodataset huggingface dataset:
Upgrade socket.io server to v3

https://socket.io/docs/v3/migrating-from-2-x-to-3-0/index.html

* We should be setting allowed origins
* We must be enabling the cookie
* Middlewares that we expect to always fire need to be explicitly added to any other namespaces
* socket.io-redis will need to be upgraded to 6.x.x
* join and leave can have callbacks removed
* code listening to Manager events (open, error, close, etc) need to be moved to socket.io.event
* Need to make sure that object ids for room names get changed to strings
* switch to "socket.io-msgpack-parser"
* remove @types/socket.io 
* set
```
const io = require("socket.io")({
  allowEIO3: true // false by default
});
```
* set maxHttpBufferSize: 1e8 to a larger value

socket.io controls all socket connections except the whiteboard.

## Tasks

Smoke tests:

- [ ] Dashboard works, specifically the waiting sessions queue
- [ ] Volunteer can join session
- [ ] Chat works
- [ ] End a session ends the session for both users, when ended by student, or by volunteer

Story points: 5.0
Devise referral uri and parameters

We need to determine what uri assistments should send the referral on and what the parameters should be.
* has to be a GET request
* parameters should be query parameters
* need to be able to transition from that url to a session for a logged in student
* need to be able to transition to sign-in, and then to a session using the parameters, when a student visits who is not logged in

Story points: 0.0
FRONTEND: favorited volunteers list in student coach page

Update student profile view to display favorited volunteers

* create a new link in the sidebar to the coach page
* add a new route that renders the coach page view
* create small `FavoritedVolunteer` card component expecting to take the volunteer name, id, and number of past sessions with the student
  * include the [toggle favorite component](1005) that calls `POST /api/student/favorite-volunteer`
* retrieve paginated list of favorited volunteers from `GET /api/student/favorite-volunteers`
* within the coach view instantiate a card component for each of the favorited volunteers
* when a volunteer is unfavorited the list DOES NOT update - until the student leaves the view or refreshes they will have the opportunity to re-favorite

See Student Profile v1.3: https://www.figma.com/file/EaawhUyLG36EQDtJhKatzStS/WebApp-Redesign-2019?node-id=37%3A161

Note: You do not need to add the subjects under the total session amount that a student has had with the tutor

## Tasks
- [ ] Code review
- [ ] Staging smoke tests
- [ ] Merge to main
- [ ] Deploy to prod

## Smoke tests
- [ ] Student/volunteer can login
- [ ] Student/volunteer can make/join session
- [ ] Student/volunteer can use whiteboard and chat in session
- [x] Coach page with favorited list renders
- [x] List paginations works
- [x] Unfavoriting a volunteer does not change the list until refresh

Story points: 1.0
FRONTEND: component to toggle volunteer favorite status

Create component for favoriting a volunteer (see V1.3 [here](https://www.figma.com/file/EaawhUyLG36EQDtJhKatzStS/WebApp-Redesign-2019?node-id=37%3A161))

Component:
* boolean prop that is toggled
* can render a heart as a view for the component
* has different style states for when boolean prop is toggled

Encapsulated logic (moved to a new ticket): 
* when clicked on opens modal to confirm whether user wants to favorite/unfavorite volunteer
* hits `POST /api/student/favorite-volunteer` to toggle the volunteer favorite status in the backend
* on error pop up error modal
    * if error is that student has max favorites include that in the modal


## Tasks
- [ ] Code review
- [ ] Staging smoke tests
- [ ] Merge to main
- [ ] Deploy to prod

## Smoke tests
- [ ] Student/volunteer can login
- [ ] Student/volunteer can make/join session
- [ ] Student/volunteer can use whiteboard and chat in session

Story points: 3.0
BACKEND: endpoints to check if volunteer is favorited and retrieve list of favorited volunteers

1. Create endpoint to check if the current student can favorite more volunteers
   * `GET /api/student/remaining-favorite-volunteers`
   * parse the student id from the request authenticated user
   * on `200` return integer counting number of favorite slots available
1. Create endpoint to check if a provided volunteer ID is favorited by the current student
   * `GET /api/student/favorite-volunteer/:volunteerId`
   * parse the student id from the request authenticated user to prevent possible abuse
   * on `200` return a boolean indicating if the volunteer is currently favorited or not
1. Create endpoint to retrieve paginated list of favorited volunteers of a given student
   * `GET /api/student/favorite-volunteers` with pagination page number on query param
   * parse the student id from the request authenticated user to prevent possible abuse
   * handler function must get paginated list of favorited volunteers and find total number of sessions with the student and volunteer
   * sort list by recency with which the student has had a session with the volunteer
   * returns something like

```typescript
type FavoriteVolunteer = {
  id: ObjectId,
  firstName: string,
  numSessions: number,
}

type FavoriteVolunteersResponseType = { body: FavoriteVolunteer[], isLastPage: boolean }
```

## Tasks
- [x] Update swagger docs
- [ ] Code review
- [x] Staging smoke tests
- [ ] Merge to main
- [ ] Deploy to prod

## Smoke tests
- [x] Student/volunteer can login
- [x] Student/volunteer can make/join session
- [x] Student/volunteer can use whiteboard and chat in session

Story points: 1.0
BACKEND: endpoint update volunteer favorited status

Create endpoint to update a volunteer in a student's set of favorited volunteers

* `POST /api/student/favorite-volunteer:volunteerId` with payload on `req.body` including a favorited boolean and an optional session id
* parse the student id from the request authenticated user to prevent possible abuse
* else if the student already has `FAVORITE_LIMIT` volunteers favorited then return an error code with a message
* on successful `200` return a boolean indicating if the volunteer is currently favorited or not
* Record a user action of `VOLUNTEER_FAVORITED` or `VOLUNTEER_UNFAVORITED` with the student id, volunteer id, and optional session id whenever the status changes

## Tasks
- [ ] Code review
- [ ] Staging smoke tests
- [ ] Update swagger docs
- [ ] Merge to main
- [ ] Deploy to prod

## Smoke tests
- [ ] Student/volunteer can login
- [ ] Student/volunteer can make/join session
- [ ] Student/volunteer can use whiteboard and chat in session
- [ ] Hitting endpoint while logged in as student updates volunteer status
- [ ] User action is recorded on both favorite and unfavorite

Story points: 2.0
DATABASE: favorite volunteers data model

Add `student_favorite_volunteers` table to the schema
```sql
CREATE TABLE student_favorite_volunteers (
    student_id uuid NOT NULL,
    volunteer_id uuid NOT NULL
    created_at timestamp without time zone NOT NULL,
    updated_at timestamp without time zone NOT NULL
);
ALTER TABLE ONLY upchieve.student_favorite_volunteers
    ADD CONSTRAINT student_favorite_volunteers_student_id_fkey FOREIGN KEY (student_id) REFERENCES upchieve.user(id),
    ADD CONSTRAINT student_favorite_volunteers_volunteer_id_fkey FOREIGN KEY (volunteer_id) REFERENCES upchieve.users(id);
```

## Tasks
- [ ] Code review
- [ ] Staging schema update
- [ ] Merge to main
- [ ] Prod schema update

Story points: 1.0
FRONTEND: Session recap view

* Create new call in NetworkService that calls `api/session/:sessionId/recap`
* Create a new view, `SessionRecapView`, in `src/views` for the session recap page
  * Calls the new NetworkService call in the previous bullet point
  * This view consists:
    * User information
    * Chat component (use the one in the admin chat but abstract it out to be used in both session recap and admin page)
    * Doc Editor component (conditionally rendered based on type of session - update the current DocEditor component to take a prop that is triggers a read only view)
       * Do not emit socket events or show toolbar in this read only view
    * Whiteboard component (conditionally rendered based on type of session)
* Include the new favoriting volunteer component created in #1005 to the Session Recap view for students only
* Create new path, `/sessions/:sessionId/recap`, in `src/router.js` that renders SessionRecapView

Design: https://www.figma.com/file/JPZ9LQZ8ytnvS07WqLZprx/Session-History%2F-Coaches%2FProfile?node-id=2%3A21584
- Whiteboard + Doc Editor follow 1.1 
- Rest of Design follow 1.2
- Web and Mobile Web (responsive version of web) only


## Tasks
- [ ] Code review
- [ ] Staging smoke tests
- [ ] Merge to main
- [ ] Deploy to prod

## Smoke tests
- [ ] Student/volunteer can login
- [ ] Student/volunteer can make/join session
- [ ] Student/volunteer can use whiteboard and chat in session
- [ ] Student recap view should match design specs

Story points: 3.0
BACKEND: Session recap endpoint and mock query

* Create a new mock query, `getSessionRecap`, in `server/models/Sessions/queries` (or the respective file where Postgres queries are held) that returns the same projection of a session `getSessionHistory` (https://gitlab.com/upchieve/subway/-/issues/992) + quillDoc:
  * `subject`
  * `createdAt`
  * `timeTutored`
  * `volunteerFirstName`
  * `volunteerId`
  * `isFavorited`
  * `studentFirstName`
  * `studentId`
  * `id`
  * `quillDoc`
* Create a new endpoint `GET api/session/:sessionId/recap` which will call `getSessionRecap` and fetch the whiteboard if the session subject required one
* Create Postgres query and write tests for it
   * Add to the seed data to be able to quickly test this feature and for future testing purposes

Note: Once the Postgres migration is complete, the mock `getSessionRecap` query will be replaced with the actual Postgres query in https://gitlab.com/upchieve/subway/-/issues/997

## Tasks
- [ ] Code review
- [ ] Staging smoke tests
- [ ] Merge to main
- [ ] Deploy to prod

## Smoke tests
- [ ] Student/volunteer can login
- [ ] Student/volunteer can make/join session
- [ ] Student/volunteer can use whiteboard and chat in session
- [ ] Hitting endpoint with Postman should return mock query results

Story points: 2.0
FRONTEND: Session history view

* Create a NetworkService call to the server endpoint `api/session/history`. It should have a query param for a `page`
* Create a `SessionHistoryView` in `src/views` that will hold a paginated list of sessions. It should call the NetworkService function created in the previous bullet point. It'll retrieve mock data from https://gitlab.com/upchieve/subway/-/issues/992
* Create a new path, `/sessions/history`, in `src/router.js` that renders `SessionHistoryView`
* Create a linkable "component" (do not *need* to create a new component file for this since this will only be rendered to this view) that links to the session recap page, `/sessions/:sessionId/recap` for the session. This "component" requires the following info to be displayed:
  * Session Subject
  * Date and time of session
  * Duration of session **(uses timeTutored off of the session)**
  * First name of partner (if a student is viewing the session history page, show the volunteer's name and vice versa)
* Include the new favoriting volunteer component created in #1005 to the Session History view for students only

Design (Session History v2.1) https://www.figma.com/file/JPZ9LQZ8ytnvS07WqLZprx/Session-History%2F-Coaches%2FProfile?node-id=2%3A17816

## Tasks
- [ ] Code review
- [ ] Staging smoke tests
- [ ] Merge to main
- [ ] Deploy to prod

## Smoke tests
- [ ] Student/volunteer can login
- [ ] Student/volunteer can make/join session
- [ ] Student/volunteer can use whiteboard and chat in session

Story points: 1.0
FRONTEND: Session history in student sidebar and feature flag

* Create a feature flag called `session-history` in the Subway repo
* Add "Session History" to the student sidebar that links to `/sessions/history`
  * Should be underneath "Dashboard" in the sidebar
  * Wrap this in the `session-history` feature flag. Add the feature flag to the [feature flag store](https://gitlab.com/upchieve/subway/-/blob/main/src/store/modules/feature-flags.js#L51) and create a getter for it called `isSessionHistoryActive`
* Keep the feature flag off for production

See design (Session History v2.1 as example): https://www.figma.com/file/EaawhUyLG36EQDtJhKatzStS/WebApp-Redesign-2019?node-id=37%3A161

## Tasks
- [ ] Code review
- [ ] Staging smoke tests
- [ ] Merge to main
- [ ] Deploy to prod

## Smoke tests
- [ ] Student/volunteer can login
- [ ] Student/volunteer can make/join session
- [ ] Student/volunteer can use whiteboard and chat in session
- [ ] Student should see "Session History" in sidebar

Story points: 1.0
BACKEND: Session history and recap Postgres query

* Replace `getSessionHistory` with actual Postgres query
* Replace `getSessionRecap` with actual Postgres query


## Tasks
- [ ] Code review
- [ ] Staging smoke tests
- [ ] Merge to main
- [ ] Deploy to prod

## Smoke tests
- [ ] Student/volunteer can login
- [ ] Student/volunteer can make/join session
- [ ] Student/volunteer can use whiteboard and chat in session
- [ ] Students should be able to retrieve their actual session history

Story points: 1.0
BACKEND: Session history endpoint and mock query

* Create a new mock query, `getSessionHistory`, in `server/models/Sessions/queries` (or the respective file where Postgres queries are held) that returns a list of the user's past sessions (remember to exclude any current sessions) with a projection of:
  * `subject`
  * `createdAt`
  * `timeTutored`
  * `volunteerFirstName`
  * `volunteerId`
  * `isFavorited`
  * `studentFirstName`
  * `studentId`
  * `id`
* `getSessionHistory` query should take in a user id, return a limited set to support pagination, and all sessions should have `timeTutored` > 0
* Create a new endpoint `GET api/session/history` to retrieve history of sessions that calls `getSessionHistory`, expects a page number as query param
  * This should retrieve the user's ID from `req.user`
* Create Postgres query and tests for it


Note: Once the Postgres migration is complete, the mock `getSessionHistory` query will be replaced with the actual Postgres query in https://gitlab.com/upchieve/subway/-/issues/993

## Tasks
- [ ] Code review
- [ ] Staging smoke tests
- [ ] Merge to main
- [ ] Deploy to prod

## Smoke tests
- [ ] Student/volunteer can login
- [ ] Student/volunteer can make/join session
- [ ] Student/volunteer can use whiteboard and chat in session
- [ ] Hitting endpoint with Postman should return mock query results

Story points: 3.0
Backend: Fix broken reference objects

Context of the issue: https://gitlab.com/upchieve/subway/-/issues/962#note_823802880

- This line of code https://gitlab.com/upchieve/subway/-/blob/main/server/services/VolunteerService.ts#L245 should be inside the if block with the line above it `UserActionCtrl.AccountActionCreator(volunteerId).accountApproved()`
- Dynamically build the `update` object https://gitlab.com/upchieve/subway/-/blob/main/server/services/VolunteerService.ts#L222 only if there are truthy values for the reference statuses
- Create a DB script to remove all broken references from volunteers


## Tasks
- [x] Code review
- [x] Staging smoke tests
- [x] Merge to main
- [ ] Deploy to prod

## Smoke tests
- [x] Student/volunteer can login
- [x] Student/volunteer can make/join session
- [x] Student/volunteer can use whiteboard and chat in session
- [x] Volunteers should be able to add and delete references
- [x] References should be able to submit a reference form
- [x] Admins should be able to see pending volunteers
- [x] Admins should be able to approve or reject separate approval process steps and should not result in broken references for the volunteer

Story points: 2.0
Frontend: Fix closed whiteboard socket after connect-error

See for context on the problem: https://gitlab.com/upchieve/subway/-/issues/983

Make the changes proposed in the "Proposal" section of this comment: 
https://gitlab.com/upchieve/subway/-/issues/983#note_825175160

- Remove `this.zwibblerCtx.stopSharing()` in https://gitlab.com/upchieve/subway/-/blob/main/src/views/SessionView/Whiteboard.vue#L661
- Remove the `isSessionConnectionAlive` watcher. We don't _need_ to call `joinSharedSession` https://gitlab.com/upchieve/subway/-/blob/main/src/views/SessionView/Whiteboard.vue#L751 since Zwibbler will attempt to reconnect to the whiteboard server (as long as we don't call `stopSharing`) and join the collaboration server on its own. Please validate this first with further testing on this behavior. If this cannot be removed, simply put an `await` before `joinSharedSession`. 
- Remove `this.zwibblerCtx.newDocument()` https://gitlab.com/upchieve/subway/-/blob/main/src/views/SessionView/Whiteboard.vue#L750, see docs for [newDocument()](https://zwibbler.com/docs/#newdocument)


## Tasks
- [x] Code review
- [x] Staging smoke tests
- [x] Merge to main
- [x] Deploy to prod

## Smoke tests
- [x] Student/volunteer can login
- [x] Student/volunteer can make/join session
- [x] Student/volunteer can use whiteboard and chat in session

Story points: 2.0
Fix document editor text issues

The document editor has text issues because of race conditions with Redis. You can see more of the findings here https://gitlab.com/upchieve/subway/-/issues/938. 

There's currently a working draft that uses Redis lists https://gitlab.com/upchieve/subway/-/merge_requests/939, however discussion has not been finalized on using Redis transactions or Redis lists.


## Tasks
- [x] Code review
- [x] Staging smoke tests
- [x] Merge to main
- [ ] Deploy to prod

## Smoke tests
- [x] Student/volunteer can login
- [x] Student/volunteer can make/join session
- [x] Student/volunteer can use whiteboard and chat in session

Story points: 1.0
FRONTEND: new banner copy and condition

On frontend copy logic for display of original banner but read `UPF.partnerSchoolGatesQualified` instead

* use MR [!864](https://gitlab.com/upchieve/subway/-/merge_requests/864/diffs#93cf7a75f81c2ba33e2e20b9d3a85aa4d00eee53) as a template
* reuse the existing feature flag to gate whether banner is shown
* the copy of the existing banner can be defined by a ternary on which banner to show
* make the condition on displaying the banner be `date before 1/28 AND feature flag on`

## Tasks
- [ ] Code review
- [ ] Staging smoke tests
- [ ] Merge to main
- [ ] Deploy to prod

## Smoke tests
- [ ] Student/volunteer can login
- [ ] Student/volunteer can make/join session
- [ ] Student/volunteer can use whiteboard and chat in session
- [ ] Old banner displays for non partner qualifying students
- [ ] New banner displays for partner school qualifying students

Story points: 1.0
BACKEND: migration script for partner school students

Create backfill script on all student accounts made since 10/13/21

* check if UPF.gatesQualified || UPF.partnerSchoolGatesQualified is true
* if true pass
* else run `processPartnerSchoolGatesQualified` on student

Only run script once #979 is deployed

## Tasks
- [ ] Code review
- [ ] Staging smoke tests
- [ ] Merge to main
- [ ] Deploy to prod
- [ ] Run script against prod

## Smoke tests
- [ ] Student/volunteer can login
- [ ] Student/volunteer can make/join session
- [ ] Student/volunteer can use whiteboard and chat in session

Story points: 1.0
BACKEND: GatesStudyService for partner schools

add `processPartnerSchoolGatesQualified` GatesStudyService listener to `student-created` event doing similar logic to existing gates check

* check if 9th or 10th grade
* check if school belongs to custom list in [google doc](https://docs.google.com/document/d/1bj5mFn8zgGS-tNMtf5qsZlhWP6n6ljCJi18tiqRo00s/edit)
  * parse list form config key
* add new product flag `partnerSchoolGatesQualified` and set that to true

## Tasks
- [ ] Code review
- [ ] Staging smoke tests
- [ ] Merge to main
- [ ] Deploy to prod

## Smoke tests
- [ ] Student/volunteer can login
- [ ] Student/volunteer can make/join session
- [ ] Student/volunteer can use whiteboard and chat in session
- [ ] New student with relevant partner school gets partner gates flag set to true

Story points: 2.0
BACKEND: Add IPWhois API Key

We should add the IPWhois API key to config since we are no longer using the free version. We need to refactor so that the backend uses the key, and refactor any necessary frontend calls that go through the backend

## Tasks
- [ ] Code review
- [ ] Staging smoke tests
- [ ] Merge to main
- [ ] Deploy to prod

## Smoke tests
- [ ] Student/volunteer can login
- [ ] Student/volunteer can make/join session
- [ ] Student/volunteer can use whiteboard and chat in session
- [ ] Ensure eligibility IP checks still work

Story points: 1.0
Bug: Only follow-up text being received by a volunteer

From Academic Coach Slack:

Addison Doherty  11:18 PM
I’m not sure if this is happening to anyone else, but recently I’ve only ever been texted with the “heads up” text, I haven’t received any texts saying that a student needs help beforehand![Image_from_iOS__2_](/uploads/15ceb282d45e624cce10e4c6636e0a65/Image_from_iOS__2_.png)

## Tasks
- [ ] Code review
- [ ] Staging smoke tests
- [ ] Merge to main
- [ ] Deploy to prod

## Smoke tests
- [ ] Student/volunteer can login
- [ ] Student/volunteer can make/join session
- [ ] Student/volunteer can use whiteboard and chat in session

Story points: 3.0
BACKEND: Add partner students helped column to analytics report for AT&T and Verizon

The AT&T / Verizon volunteer reports should have new columns/metrics added (see the things shaded in yellow [here](https://docs.google.com/spreadsheets/d/1KYwNIRtmqakJ_NX0TrWlFMG3Mr1-YPCJ1FioXjp9akw/edit#gid=833012707)). Essentially:

* Sumary: total unique AT&T/Verizon students helped by AT&T/Verizon volunteers
* Per volunteer: total sessions and tutoring hours completed with AT&T/Verizon students
* Per volunteer: total unique AT&T/Verizon students helped
* NOTE: we do not care if the sessions used to compute the stats above we matched due to the new priority filters - just that the volunteer and student came from the same org

Up to your discretion if these columns are part of a new report just for AT&T/Verizon or if they are added to the existing analytics report. If you do make a new report you must also add a button to the frontend to request to generate that report.

## Tasks
- [ ] Code review
- [ ] Staging smoke tests
- [ ] Merge to main
- [ ] Deploy to prod

## Smoke tests
- [ ] Student/volunteer can login
- [ ] Student/volunteer can make/join session
- [ ] Student/volunteer can use whiteboard and chat in session
- [ ] Admins can generate report

Story points: 1.0