tritonse / maw-volunteer-hub Goto Github PK

Work closely with @mohakvni to develop and integrate the wish granting page. We should have all of the frontend components necessary to do so.

There might be some issue with downloading all files in a category. This will probably require a separate route that pulls all files from AWS, compresses them into a zip, and serves them to the frontend to be immediately downloaded.

Add more information to readme, including development information, application description, etc.

Make a component to display a list of user objects passed in through props. Make sure this component is developed with the final version in mind, where we will be adding many more columns (up to four). I included the pictures for both the MVP (which is what you are making for this issue), and the final version just so you know what I'm talking about. The easiest way to do this will probably be some sort of react table package.

MVP Version

Final Version:

Check in with designers during meeting on how to make this mobile compatible. I think it'll be hard to make the entire table fit onto one screen, so a horizontally and vertically scrolling table will probably have to do.

Note: Blocked right now, waiting on design feedback

Need to create some sort of group contact card as in the image below. We won't exactly follow the image below. Instead, we will extend this functionality to allow the admins full flexibility in creating these groups (this will honestly be easier to implement).

We will need:

• Contact Group Card Component - visual display for this card component. Should show arbitrary title, description, and contacts
• Modals for creating / updating contact groups (similar to the individual contact process)
  • These modals should have fields for title, description, and up to 4 contacts
• The delete model should prompt a confirmation modal (Are you sure you want to delete)
• These modals should rely on a database model for storing/persisting these contact groups. Will need to make a new model for these contact groups. Will need to make basic crud routes for creating, updating, deleting, and getting groups.

We already have the frontend for the log in and sign up, and now have the backend for it set up and ready.

This issue encapsulates linking the frontend and backend together

1. The user should be able to sign up for an account by filling out the form and submitting. This should hit the /auth/signup route with the correct information, and respond to the user whether or not the sign up was completed
2. The user should then be able to use the account information they just created to sign in. The form should hit the /auth/login route with the correct information, and respond whether or not the log in was successful.
3. If the login was successful, the response will contain a JWT token. Store this in local storage. This will be passed into every api call from the frontend
   (For 1 and 2, it might be good to create an authUtil file to contain the api logic for accessing the backend.
4. If the user does not have a valid JWT token, they should be redirected to the login page (no matter what link they try to access).

When a user signs up for an event or is added by an admin, they should receive an email with the details of the event

EDIT: Add a new category "Other" at the bottom of the sidenav

The final page for version 3 is the Additional Resources page. It's almost completely identical to the Wish Granting page we currently have.

Should be a pretty simple task. May need some small changes to the backend (but looking at it I don't think so).
For the frontend, will need

• New Page for additional resources with identical functionality to current wishweds page
• Add new page to routing
• Add new page to navbar

User schema for v1 contains

Name,
Email,
Verified (initially false on creation),
Active,
Profile Picture,
Roles array

Needs to be done in conjunction with Auth0

Have to wait for the desktop side navigation (#15) and file + category components (#24) to be merged.

This issue is two fold

1. Template out the Wish Granting page
   
2. Develop modals for creating, editing and deleting both files and categories
   

The category and file components should open these modals when the respective edit, delete, and create buttons are pressed.

Contact page viewing, editing

Make a new model for wish wednesday. Should include a history of past wish wednesday posts.

Make routes for creating and retrieving the most recent wish wednesday post.

Integrate with home page to display most recent wish wednesday post.

There's an edit button on the figma, and I'm not 100% sure what it's use case is. Currently it's commented out but we should implement before final deploy

Currently, the navbar is the same for admin and regular users, but this shouldn't be the case.

The navbar should only show the manage tab if the user is an admin.

Complete the navbar component. This should include routing between pages, the dropdown for when the account button is clicked, and the designs for the searchbar (doesn't have to be functional).

There is already an existing navbar component in the component directory, so feel free to use this as a starting point (it is very barebones).

Develop the following three components and place them on the profile page. For now, the will not be connected to the backend, but the PR will not be merged until a separate task completes the integration of these components.

The first (top left) should scroll horizontally and show all of the user's roles.

The second (top right) should simple show the number of events a user has completed.

The third (bottom) should show the specific events completed by the user. It should show as a table (similar to the user table in the manage page) and scroll with a sticky header.

• Error dialogs on fail
• Only admins should be able to see add, edit, delete buttons
• Loading bar for progress (and if not a loading bar, just a spinner so the user has some feedback)

Create two new routes

1. Update password route. This should only be allowed if the user id is the same as the current user's jwt id (look at this it might be helpful https://blog.logrocket.com/implementing-a-secure-password-reset-in-node-js/ )
2. Delete a user by id. This should only be allowed by admins. Admin account cannot be deleted, only regular user accounts. Users should not be able to delete anyone's profile (not even their own)

Depends on #17 and #15

Template out the User Manage Page. This includes the navigation bar on the right, the user list, the search feature, and the multiple types of user tabs.

The search feature should be functional, so that when text is typed it will filter all users in the current user type (admin vs volunteers) based on their names.

The different tabs on top (admin and volunteers) should change what type of user is being shown based on which is active.

A user's name (or maybe the whole entry) should be clickable. When clicked, it should route you to /user?id=<USER_ID> (this wont work yet, this will be fixed by a task later down the line).

Create the following routes:

1. Set user roles. The request body should contain a roles object. This object will look like the following:

{
    "Wish Granter": true,
    "Volunteer": true,
    "Mentor": false,
    ...
}

It must include every single role specified below. If not, it is a malformed request. Set the user's role list to include exactly every single one of the roles that was specified to be true, and none of the roles that were specified as false.
2. Get users by role: returns a list of users that have a specific role
These are the allowed roles:

saw a small issue with the mobile searchbar onblur, where typing some input then pressing the searchbar would close the searchbar, I believe the fix is just adding:
input === "" in the if statement on line 89 of Search.js

from #66

Talk with Andrew about this because he worked on the routing

Update the user page so that it displays the information for the given user id. i.e., the page /user/1234 should show the user page for the user with id 1234. If this user does not exist, it should redirect to the 404 page.

Remove unused tabs from the side nav
Remove deactivated option on mobile manage page navigation

Category

1. Get all categories of a certain "Category Type" (Discovery, planning, etc)
   2. Get category by category id -- includes all file information with this specific category id
2. Patch (edit) specific category by id
3. Delete specific category
4. Create new category

File

1. Get file by file ID
2. Patch (edit) specific file by id
3. Delete file
4. Create file into a specific category
5. Search (get) all files by name

NOTE: All of these should be admin locked routes besides the get routes.

Connect our user system with auth0

https://auth0.com/blog/connecting-auth0-to-mongodb/

(will expand in more detail later)

Integrate the new routes from #45 into the user manage page. When the blue verify user button is clicked, the user should become verified.

Ask Juliet and Andrew about the frontend implementation for the v1 admin promotion.

Create the UI for the two other parts of the Manage page, the wish wednesday and the message tabs. Both of these require some sort of Rich Text Editor, I believe Draftjs (https://draftjs.org/) would be good for this.

Depends on #15

Implement mobile styling for the side navigation component. Unsure of design specs right now.

Make a template for the account page for each user. This page should include dummy data at this point (just hard code in the names, image, etc).

When the change password button is pressed, a modal should appear like below (Don't worry about making this functional, just make sure everything looks good).

In addition, when the delete account button is clicked, a modal should pop up and ask the user to confirm the deletion (Again, don't worry about making this functional, just make sure the modal opens and closes)

Now that we have the Side Nav and users list completed, put together these components and finalize the rest of the Manage page

This will include

1. Making a search bar for the users currently being displayed
2. Making two tabs, one for admins, the other for regular users
3. Templating all components together onto the page

Make a list of test users to make sure the search and categories work!

Create two components

1. A "File Entry" component, where it shows the name of the file,
   
2. A "Category" component, where it expands on click to show children file components. It should take in a list of file objects and render them into File Entry components. If the list passed in through props is empty, then show text saying something like "There are no files in this category".

Make the buttons in the file entry and category components clickable, but just make it alert something like "Add file clicked for category ___".

The mobile styles for the nav bar are a bit more complicated than what I had expected, so merge the desktop in first and work on the mobile styles in a separate branch.

Mobile styles for the nav bar can be found on the version 2 (WIP) page on the Figma.

First, figure out how to upload files in MongoDB and express. Then, implement a super rudimentary (proof of concept) file uploading backend.

This is a super wide-scope idea which is why I didn't want to put a lot of restrictions on the task. This doesn't have to be final at all because it a super big undertaking, but I want to make sure we figure out how to do this earlier rather than later because it will be a significant part of the MVP.

Make a generalized side navigation component that renders content on the right based on which page is selected on the left.

This component comes up in the Wish Granting and Manage tabs in the MVP. Because of this, we want to be able to reuse it between pages and with arbitrary tab names and content. One possible way to do this would be to pass in an array of object in the following form

{
    tab_id: ___,
    tab_name: ___,
    tab_content: <content represented in jsx>
}

This should be mobile compatible (ask designers during 1/14 meeting about how to make this possible, maybe floating / sticky nav button that expands a drawer).

Create the layout for the login / Create Account page. This should include the logo, section for user input, and the ability for the user to switch between the sign-up and log-in views. The "create account" button should be greyed out until all fields are filled in (like in the designs).

Mostly completed by Mohak.

Need to implement edit and delete functionality (modals included)

Event Calendar

Every page loads differently. The common principle is to display everything that doesn't need loading immediately and provide a loading indicator while data is being fetched.

On slow bandwidth, the profile page loads two buttons, then a blank profile image, then events, etc.

On the admin user management page, the buttons and view only load after the users have been fetched. We should be able to load the entire page besides user content and have a loading circle in the chart to indicate the page is working.

On the files page, there is no indication that files are loading. Users are presented with a completely blank category until all files are fetched.

depends on #54

Integrate the delete user button and change password button on the profile pages.

Only admin users should be able to see the delete user button. Only the specific user should be able to see the change password button.

Rename "Wish Enhancements" to "Wish Boosts" across the website, this includes backend and frontend
(requested by the client in 2/4 meeting)

Right now, the roles have limited information besides their names, and it could be hard for the admins to know which roles to assign. We should create a hover state on the role pills and the checkboxes in the assign role modal that displays information about the role.

Requires

• Dropdown to filter by role
• Total hours volunteered on the bottom

1. Get user by id - Will return an object with the user profile information ( Only name, email, profile picture, roles, and join date )
2. Update user information (Only if JWT parses to contain this specific user id or if the JWT parses to contain isAdmin = true)
3. Upgrade user to admin by id (Only if JWT parses to contain isAdmin = true)
4. Verify user by id (I believe this already exists in #34)

(We are holding off on resetting password deleting a user by id for now)

We are going to be implementing email services for the messaging page and the account verification confirmations (and possibly the calendar notifications).

To start, we are going to get sendgrid? working with account verification emails. Essentially, when an admin approves a user and their account is verified, an email will be sent to that user notifying them that their account was approved.

Message me for the account information.

We need a route to approve users! Essentially, when a user account is created, it will have the approved tag = false. We want admins to be able to approve a user by calling this route with a user id (Security can be handled at a later point). When this route is called with a user, it will set that approved tag to be true.

We also need two more routes for displaying users

1. A get route that returns a list of all non-admin users
2. A get route that returns a list of all admin users

This will be used to integrate the users page!

Relies on #16

Create basic templates for the following search modals. The first will be hard to do because we haven't finished #16, but figuring out the bottom "empty" modal is possible without the components. Make sure the search values are passed in from the search bar into the modal.

Create two models

1. File Model
   Should contain

• Unique file id (not mutable)
• Name of file specified by user
• ID of user who last edited the file
• Time of file creation
• Time when the file was last modified
• Category ID of parent category (Not mutable)
• File binary (Binary encoding of pdf, this should be done with the research from #19

2. Category Model
   Should contain

• Unique category id
• Name of category specified by user
• Name of parent category (only possible values are DISCOVERY, PLANNING, ENHANCEMENTS, REVEAL, CLOSEOUT) see these on figma
• ID of user who uploaded file
• Time of category creation
• Time when the category was last modified
• List of File object IDs (or references to the file objects)

A very open ended issue

Start looking into how we can implement the calendar for V2, including what packages to use for the frontend and how to utilize the google calendar api to export calendar events.

We are now pivoting to using PassportJS over Auth0 for a couple of reasons.

For this task, I want you to

1. Finalize the backend process for creating a new user, and authenticating a user on login (More or less an extension of #3)
2. Research JWT, I sent you an article on account and user authentication with the PassportJS JWT process.
3. Figure out how to create JWT locked routes (This should also be in the tutorial I sent). Most routes on the website should be protected, so routes shouldn't be available to users that are not logged in and do not have a JWT token
4. Figure out how to encode an admin tag into the JWT token. This will be vital because there are also a number of routes that should only be available to admin users. For these routes, we will decode the JWT passed into the route by the user. If it does not include this admin property, then the admin locked route will instantly fail.