hack4impact-calpoly / hospice-of-slo Goto Github PK

Users cannot get the full effect of the discussions because it is a little hard to visually tell who is in the conversation, who posts messages, etc.

Attempt to make this more digestible for users, perhaps similar to iMessage conversations where messages are split on two sides of the screen and color coded.
May involve:

• Checking which messages are from the logged in user and which are not.
• Using conditional JSX to render different styled components.
• Making new components for messages that have different styles

If you have ideas, add other visual features you think would be helpful, without overcrowding the screen. Hospice SLO does not want a lot of superfluous features, but they want it to be extremely easy to understand.

Popup a simple modal that displays shift details when clicked. This component should just make the info easier to see visually.

• Currently, details display when you hover over a shift, and these details display on the right side of the screen.
• Remove this, and instead:
• On click, use a modal to pop up details of the shift. (could use the existing code written, just move it to a modal)
• Ensure it is very easy to read on mobile and desktop.

Update the user data formats to add an isValidated field. This should be false when users are created. Later on, we will add a way for admins to manually validate users. This may involve updating any place a user is passed around to include this extra field.

(if a better way to do this via firebase is found we will let you know today, 1/25/2022)

if you have extra time and want more for this task, ask Ritvik and Ben!

This task involves using the modal that was created for the shift signup and linking that form to create an event that will display on the calendar and send it's data to the backend. This is pretty straightforward, currently the modal will pop up on click and has its data stored in variables.

You will need to connect the newly made modal to the new calendar as it is connected to the old calendar at the component.
You may want to look at the old calendar to see how things are displayed.
You can also look at the createVigil.jsx file to see how data is sent to the backend.

Let Ben and I know if you have any questions!

Create a new page that only admin accounts can see, include the same theme header other pages have.
Create a link to this new page on the navbar. Follow the formatting on the navbar.
Get a list of users who are not validated (you can just print this to the console or as plain text to the screen for now)

Checkpoints:

• New page with same formatting as others
• Test visibility between admin and non admin
• Ensure link works on navbar
• All users should be in the store (check out line 43 in contacts.jsx for example)

The new validation page holds a list of users awaiting validation. Currently, when an admin presses accept/reject it just prints a message to the console.
First add a confirmation popup when a user is accepted/rejected. Should print a message along the lines of "are you sure you want to accept/reject [username]".
Next, please link these buttons to the backend so when they are accepted, their isValidated field is set to TRUE. When they are rejected, their user document should be deleted from the database.
Also, remove that user's validation object from the frontend once the button is pressed.
Le us chow if you have questions!

Please try to break the site. Put in bad inputs into forms, try to use incorrect/invalid dates, think of common mistakes users might make, attempt to inject code, use different internet strengths, try to test on different operating systems, test different window sizes.

Anything you can think of that may break the site, test it. When you can, have the dev console open so you can see if there are errors not seen by users (maybe a bad request).

If you are on this task, comment what OS and browsers (try to use multiple) you are going to test on.
If you find a bug, comment it here.
Then, see if you can fix it on it's own branch.
Update your comment to note if you did/did not fix it.

Hospice admins want to remove some current pages which are no longer needed.

• Admin History page
• Remove past shifts/blocked off shift page, and current calendar
• Link the new calendar to the navbar so navigating links us to our new pages
  For this task, remove all references to these pages and their components from App.js, the navbar and any other pages that link to them.
  Do NOT delete the component files themselves, we will keep the old code until we hand off to the nonprofit.

This task will need 2 people.

Go into the database and add some test data for the past shifts, discussions, and calendar.

After you have added some test data look around the site to make sure that the data was added properly and the site still functions properly. If something doesn't work then write up a description of the issue and attach it below.

For this task you will have to implement some way or package so that when a user posts a discussion message it sends an email to everyone in the discussion.

This will include:

• Getting a list of all users who have sent a message in the discussion and sending them an email.
• The email should just alert the user that there is a new message, not the actual message.

Doing this with a package will be the easiest way. You may have to take a look at how the backend is setup.

The site no longer uses vigils, instead shifts will be stored in one large shifts collection. Users will not have a list of their own shifts.
Need to go through the signup functionality and remove all db operations that use vigils and the vigil shifts collection, then replace these with the new schema(see below).

1. When a user signs up for a shift, the shift should be pushed to the new "shifts" collection in the database.
2. The calendar should pull shifts from the new shifts collection in the db instead of each vigil.

They are more interested in a calendar that mirrors Microsoft outlook's. Important features and checkpoints:

• Can see visually on the calendar when people have scheduled shifts.
• Overlapping events on the calendar are not cluttered
• Use some static data to test the layout for now
• The calendar does not need any functionality yet, just an appealing UI

For this task you'll need to create a new calendar component, and leave the current one in place for now.
Making a new component will help in case anything goes wrong so you can have the old one to reference instead of changing it or in case Hospice changes their vision.

Begin with static frontend components, we are most interested in a visually digestible layout for now. See how overlapping events look, what colors are easiest to discern, etc.
We will add backend functionality at a later time.

Things of Note:

• This will likely just use full calendar package again in a different configuration. (see Ritvik or Ben for clarification)
• If there are any small bugs that arise from the change, see if you can fix them.
• If you encounter any site breaking bugs that seem like a big fix, write a description in the comments below and attach a screenshot if applicable.
• When testing you can unlink the current calendar and link yours in its place.

Full Calendar:
https://fullcalendar.io

This task will need 2-3 people

Their biggest difficulty has been with the scheduling interface for users.

Shannon wants something similar to the outlook calendar that allows her to visualize the evets easier (especially when side by side) .
She also wants the signup functionality to stay simple for users.

Currently, the site uses the FullCalendar node package for the interface. Please research alternative options to the current design.
Consider:

• Are there other packages that may be easy to use?
• Are there other configurations in FullCalendar that would be easy to change to?
• What else in the site would have to change to accommodate the new calendar?
• How much control do we have over color customization, and other UI elements?

After researching, all researchers will meet together, along with Ritvik and Ben

For this task you'll be changing our new calendar component from using static data to be able to pull data from the backend and and display them on the calendar on render.

You can make some test data in the database to test to make sure that they are correctly rendering onto the calendar component. You can also take a look at our old calendar component to see how the interaction with the backend works.

Let Ben and I know if you have any questions.

Currently, there are 'discussion threads' that doulas use to communicate about the status of a vigil. They send updates and alert the person on the next shift of any developments.

They have found it is difficult to know about updates without alerts. An email mailing list would help doulas know when someone sends a new message.

There may be a good Node package for this that would make it easier.

Things to look for/understand:

• Can we automatically enroll users?
• Does it interact with Firebase at all?
• How much control do we have over emails?
• Are we able to validate messages?
• How are users subscribed to the mailing list?

After research is complete, will quickly meet with Ben and Ritvik to discuss findings.

• For some reason, horizontal lines do not display between days of the week. See fi you can fix this
• When there are multiple shifts at the same time, ensure they are different colors and do not overlap in an unreadable way. A side-by-side view would be best here.

The admins don't want unvalidated users to have access to the site.
Using the new isValidated field in user accounts, limit what users see via protected routes in App.js.
(You may have to make a new account or manually add the field to your existing account).

If they are validated, let them see the whole site,
If they are not validated, show them the awaiting validation page (this page is being implemented separately, for this task, just direct them to an empty div or something).

For the new admin validation page, create the frontend component for each user pending validation.
What this should look like: Similar to the existing contacts page, make a component users not yet validated.
It should show their name and email. In addition, there should be two buttons to accept or reject the user.
For now, when the button is selected, just print the user's info (including their ID) to the console along with the selected choice.

Checkpoints:

• Use static test data for now, the outer page will fetch data
• Try to follow similar styling
• Ask Ben and Ritvik about more specific design requirements (sorry we have no mockups :) )

Shannon would like to be able to validate all new accounts so she can filter new, approved doulas quicker.

Ideally, this would involve her receiving an email that a new user has signed up and she can just hit 'approve', and it would link directly to Firebase.
But maybe this is more easily done via the Firebase console.

Things to consider:

• How easy is it for her to validate?
• How well does it link to Firebase?
• How does it interact with our database?
• Does it require extra work from users (hopefully not)?

After research is complete, will quickly meet with Ben and Ritvik to discuss findings.

This is a pretty simple frontend task in which you will make a page that will popup when a user logs in but isn't validated or when they sign up they will be directed to this page. The page is pretty simple it should does display a message stating the the user isn't verified and that email should have been sent to the administrator and instructing them to wait to be validated then login later and to contact their admin for any problems. This is just the frontend for this part right now.

Currently, a modal pops up when a user clicks a shift in the calendar.
Hospice of SLO is interested in possibly changing the functionality to give users more freedom with shifts.
Now, add a modal that pops up when a user clicks anywhere in the calendar.
In addition, they would like users to be able to sign other people up.

Things of note:

• This modal is not linked to a specific vigil, so you do not need to populate the vigil info, just provide a place for a user to sign up.
• This modal can look similar to the first one, however make the time inputs simpler (users do not need to say what exact second they will be there).
• Add a section for a user to input a first and last name
• Do not include the smaller mini calendar on the modal for now.
• This is frontend only, no need to make it functional yet

If you are confused on how to make a modal:
https://www.npmjs.com/package/react-modal

When a user signs up, admins should receive a notification that a new user has signed up.

Nodemailer appears to be the best route for this, but also talk to @javalosr2004 for some insight!
Checkpoints:

• After the signup button is pressed, send an email
• Will likely need to use gmail to test this, and please, use your own email :)
• Do NOT include personal info in the message itself. Just a general notification there is a new user.

Extras:
Are you able to securely supply a link in the email?
If so, attempt to link it back to the hospice slo page so admins can just enter from their email.

This is a low-priority task just to adjust the styles of the calendar and shift components to match the the styling of the site, and to just make sure they look good all together. You can take a look at the styling of the old calendar component to help you out with this one and can use some if it.