sfbrigade / compass Goto Github PK

This is the parent issue for creating the components and interaction for collecting data for a particular trial.

Subtasks:

• #101
• #98
• #94
• Flesh out the required schema for this task as part of #90
• Update backend to store data
• #95

Figma: https://www.figma.com/file/m09znscRXNqSziAiEbNLTf/Compass-Wireframes?type=design&node-id=4197-70166&t=duBg5z5djAaQ44DF-4

There should be a global error handler passed as an option to the trpc provider in src/pages/_app.tsx that shows a toast or alert on API errors.

Eventually will be used by paras to submit work.

Created using "Draw.io" -> XML file.

Edit:(Link removed)

How to Add to Google Drive:

1. Go to draw.io
2. Go to File -> Open from -> Google Drive
3. Go through and allow access from Google Drive

Then you should be able to view the link!

Tasks

• Show existing students
• Add student
• Archiving student

Design Preview:
SourceLink

As a Para, I need to be able to to collect Data using a digital counter

• Counter needs to be designed
• counter needs to be send to DS team and adjusted into Design System
• Counter needs to go to Engineering with documentation

5/17- Counter is designed and has been send to DS team

Each card represents a data collection activity for the para.

Flesh out the API - inputs needed to render the card, and create reusable components that follow the design system in collaboration with the UX team.

Figma: https://www.figma.com/file/m09znscRXNqSziAiEbNLTf/Compass-Wireframes?type=design&node-id=4197-70119&t=duBg5z5djAaQ44DF-4

Mocks:

As a para, once I've initiated a task and read the instructions, I have an interface to record data following the guidelines of the CMs instructions. If I need to, I can access the instructions for the task without disrupting the task in progress or losing any information that I've already entered. I can easily count a student's successes and attempts at a given benchmark and add any contextual qualitative notes. When I'm done, I submit the data and receive confirmation that the task is completed. The system saves the time and date alongside the data I've input and my name (but doesn't need to tell me that).

• Counter affordance for successes & attempts
• Ability to review instructions
• Ability to add qualitative notes
• Ability to submit data (finish task)

To consider: what should the behavior be if a para exits a task in progress?

As a case manager, I need to represent my student's IEP goals in Compass. I can add as many IEP goals as I need to per student. Goals have titles and descriptions. This interaction can be as simple as pasting in the official IEP description.

• Create a goal from a student profile page
• Enter a title
• Enter a description

On each individual student's page, make an IEP parent component to put Goals into. (In pages/students/student_id)

• Add a link for every Compass Logo to take the user back to the home page. All the possible places that are needed are:
  • cmDashboard
  • individual student's page - add the logo and redirect to home page
  • individual para's page - add the logo and redirect to home page

In order to make an archive property for paras, we will need relational tables to describe CM's relation to paras, using the UUID's for both parties:

ALSO make function getAllParas --> getMyParas

This may change slightly based upon if/how we restructure the CM and Para to both be Users.

• Backend Make schema/table for CMs-to-paras

• Backend: make a "create para" action in the front end flow through this sequence of queries in the back end(while carrying CM uuid as part of the req object or otherwise having access to it in the backend):

  • Backend: Query for the para (by email) in the Para table
  • Backend query: If they do not exist, add para from query body to their primary table
  • Backend: Either way, retrieve uuid of para (while carrying CM uuid)

• Backend: Put CM's uuid and para uuid in CM-to-para relational table

• Frontend: Render para lists as the response to queries of the CM-to-para table (CM's uuid in that specific relational table)

• Front-end: Make button on Para's individual page for archiving para

Edit 5/09/2023 (After convo with Max)

The purpose of this issue is to restructure the para flow as a multipurpose USER flow, meaning:

• Have the front end call user-directed functions rather than para-specific functions, only specifying the role as "para" and having role-based actions, like email invitation generation
• Eliminate the need for paras.ts in src/backend/routers folder by renaming and moving all of the para-specific trpc functions as "user" functions, to users.ts

Notes:

• The createUser function in src/backend/auth/adapter.ts is a special case due to OAuth, and should be considered its own thing. Including it in any efforts towards function reuse will not benefit the repo in any big way, since it is only called once, upon login.
• The current user logging in for the first time is currently being given the role "para", and if we start checking permissions based on roles, we can change that in adapter.ts to "case manager", but we may be moving towards Users, Admin, and SuperAdmin, rather than Case Managers, Paras, and Admin, so it may be unnecessary before we change that structure.

As a first-time para, it is important for me:

• To receive detailed instructions on how to collect data using Project Compass.
• To receive clear information about the goal that has been created for the student.

This will enable me to actively contribute to tracking the student's progress and providing the necessary support throughout students' educational journey.

Currently, the user logging in is added to the user table automatically through an internalized createUser function in a local (non-global) scope in backend/auth/adapter.ts

It would be ideal to create/reformat and export a createUser function that can be used globally in backend/auth/adapter.ts AND in the user.ts or para.ts routers files.

#login

• Deploy staging environment
• Setup HTTPS

Either backend/* or @/backend/*, not both.

In order to make an archive property for students, we will need relational tables to describe CM's relation to students, using the UUID's for both parties:

This may change slightly based upon if/how we restructure the CM and Para to both be Users.

• Backend Make schema/table for CMs-to-students

• Backend: make a "create student" action in the front end flow through this sequence of queries in the back end(while carrying CM uuid as part of the req object or otherwise having access to it in the backend):

  • Backend: Query for the student (by email) in the Student table
  • Backend query: If they do not exist, add student from query body to their primary table
  • Backend: Either way, retrieve uuid of student (while carrying CM uuid)

• Backend: Put CM's uuid and student's uuid in CM-to-student relational table (Do we need student names here also?)

• Frontend: Render student lists as the response to queries of the CM-to-student table (CM's uuid in that specific relational table)

• Front-end: Make button for archiving student

• Back-end: have CM-adding-student flow in. routers/students.ts:

• Is student email already in student table?
  • If no, add student
  • If yes, is assigned_case_manager_id null?
    • if no, send error message ('there is already a CM assigned to this student')
    • if yes (it's null), add case current manager's id to assigned_case_manager_id property

Para experience
As a para, I want to see a list of prioritized benchmark data collection tasks that are assigned to me. The most important or urgent tasks are most prominent but if I need to, I can look through other benchmark data collection tasks associated with any student on my classroom's caseload. I can easily initiate a task from this view.

• Tasks are listed
• Tasks are discoverable
• Tasks can be initated

Flesh out the data model parts that are needed for the MVP CM and para flows.

Parts to flesh out:

• structure of IEP, goals and benchmarks
• Data collection for a trial
• data collection scheduling (which populates tasks on the para dashboard)

When a CM adds a new para, send an email invitation to the para's email. We will send an email invitation only if the para hasn't logged into Compass yet.

Things to figure out:

• what happens if multiple CMs add the same para (before they have logged in). Should we send them multiple emails or just one?
• Should we send reminder emails periodically if the para hasn't logged in?

This component will be a container for the other elements for the trial data collection like counters, timer etc.

Tasks

• Show existing paras
• Add para
• Remove para

The Student list and the Para/staff list use the same form format and we could reuse code by making an interface or class and making these two forms be instances of that interface.

Tip: if you want to work on one of these, hover over the item and click "convert to issue on the right" and then assign yourself to the issue to avoid duplicate work.

• #5
• #11
• #6
• #15
• #12
• #13
• Template

Create a counter component that can be instantiated multiple times for the different use cases in the data collection flow.

The component should take color/style, labels, min/max settings etc as inputs, and should expose the counter variable as an output.

Mocks:

Figma: https://www.figma.com/file/m09znscRXNqSziAiEbNLTf/Compass-Wireframes?type=design&node-id=4260-73489&t=duBg5z5djAaQ44DF-4

Case manager experience
As a case manager, I can add a benchmark to a student's IEP goal. It should be clear that this is how I'm going to be able to collect and view data for this goal. A goal can have as many benchmarks as I want.
When creating a benchmark, I define instructions that will be conveyed to any para collecting data for this benchmark.
I also define what type of data will be collected (so far, we've only talked successes/attempts, but more data formats will be possible in the future).
Benchmarks have names and defined objectives (represented as a % of successes out of attempts). Benchmarks will have baseline metrics as well but those will be addressed in a separate ticket.

• Create a benchmark from a student's goal page
• Define instructions for how to collect data about a benchmark
• Select a data collection type (currently only successes/attempts)
• Set an objective for this benchmark

Upload the images to the cloud and associate it with the trial data collection.

Figma: https://www.figma.com/file/m09znscRXNqSziAiEbNLTf/Compass-Wireframes?type=design&node-id=4197-70166&t=duBg5z5djAaQ44DF-4

Mocks:

Implement one rpc

#backend

Para experience
As a para, I need to be able to log in to the compass app. I should be able to use my email address and a password of my choosing. If I forget my password, I can request a reset be sent to my email. This is a mobile first experience.

• Login
• Reset password

Create sign in wireframe and FE / BE implementation
Figure out role selection with product team for folks that land directly on our site

Design Preview:
SourceLink

#login

Linked to #62 , for the creation of the Relational CM -> Para table and Relational CM -> student table

This may change slightly based upon if/how we restructure the CM and Para to both be Users.

• Make button for archiving para/student
• Make a List Render request query para/student in their primary table (while carrying CM uuid as part of the req object or otherwise having access to it in the back end)
• If they do not exist, add para/student to their primary table
• Either way, retrieve uuid of para/student (while carrying CM uuid)
• Put CM's uuid and para/student's uuid in appropriate relational table
• Render para/student lists as the response to queries of relational table (CM's uuid in that specific relational table)

Example flaky run: https://github.com/sfbrigade/compass/actions/runs/5182125681/attempts/1

As a para, I can read through instructions written by a case manager about how to properly conduct a benchmark data collection task. These instructions are available when I initiate the task. If it's not my first time conducting the task, the instructions can be skipped or may not show at all.

• Display instructions from CM
• Instructions are skippable after 1st time viewing