• Always show if User is logged in (GET /auth)
• Link to Google OAuth
• Logout button (clears 🍪 )
• Your Account button

Backend Image Upload Feature

• add a field to member model for image URL/image hash for imgur
• Either update the existing endpoint or create a new endpoint that takes in an image url (imgur is a good one)

Describe the the feature request
Put request in backend that will just edit the visibility of a note.

• Displays all the fields in spreadsheet
• Make everything input fields (disable if no access)

GET /notes/labels

Return all unique note labels in the DB.
Returns a list of all current labels in order to allow user to choose from a list of current labels.

Create a /notes/:noteID route on the frontend for viewing/updating a note.
Page should display:

• Note title
• Note content
• List of editors (Be able to update editors)
• List of viewers (Be able to update viewers)
• Last edited by
• Delete button
• Note label (Fetch label options from /notes/labels. Allow users to define new labels)

Filter/Search for members in the homepage based on:

• Active Status
• Year
• Name
• Other possible useful filters too
• input for name search

Description

We're adding a cleaner look to the navbar. For new pages, it is okay to send them over to a Page Does Not Exist or of the sort if they haven't been implemented

Learning objectives

• Navigation bar development
• Cool css stuff

Todo

These points are a rough guideline. Please feel free to discuss with others on the team about the best way to design this component!

• Research ways of implementing the new navbar (refer to semantic-ui)
• Implement navbar

Useful links

• Figma Design

Description

Currently, we lead members to a different page when they click on a member. We also want a modal to pop up that will have all of the member's data populated. Where those with permissions can edit specific fields just like the current existing page.

NOTE: This relies on #101 where edit member modal will reside in this given location:

Learning objectives

• Modal implementations
• Working in parallel with another dev
• Stretch Goal: Make this new component also compatible with other types of data. Not just member data like chapters and projects

Todo

These points are a rough guideline. Please feel free to discuss with others on the team about the best way to design this component!

• Research libraries or use already imported libraries that might contain ways to facilitate modal implementation
• Create files and implement profile component
• Replace the current profile page with the new profile component
• Connect to functions in ../utils/apiWrapper.js
• Once #101 is implemented create an issue or in your PR connect to the new table and display it as a modal

Useful links

• https://react.semantic-ui.com/modules/modal/
• Figma Design

Description

Right now we want to be able to host both images of our members along with their resumes too. This might also require the need to add new fields to the Member Schema so be aware of that too.

This will eventually lead to new issues like that of allowing people to upload those specific files

To recap the two main files that we want to host in Contentful CDN are:

• Resumes
• Profile Images

Learning objectives

• CDN Integration/Development

Todo

These points are a rough guideline. Please feel free to discuss with others on the team about the best way to design this component!

• Create an account that is under [email protected] and then integrate it to our backend
• Test integration with your preferred platform (postman.. etc)

Useful links

• https://www.contentful.com/

Backend String Validation

• Validate all the string fields in the backend models. This includes phone numbers, emails, and so on.
• Update endpoints accordingly based on the validation

Delete Member Endpoint

• Remove from database
• Remove from authentication

Currently much of the frontend (especially on the Profile page), is generated from the backend. This leads to the labeling being a bit weird. For example, some enum options are "SOFTWARE_DEVELOPER" instead of "Software Developer" and labels are of the form "firstName" instead of "First Name".

To fix this, we could either:

1. Make the DB field names/values user friendly
   • This would fix the enum issues, but not the label issue
2. Format fields based on pattern
   • All DB fields are camel case, and enum fields are all capital, so it would be rather easy to derive a readable version of the fields/enums by doing string replacement
   • This would work well provided proper naming convention is always followed when adding enum options/member fields
3. Pass labels to the frontend
   • The backend could instruct the frontend how to display all fields
   • This is the most flexible, but it requires a bit of hardcoding on the backend

Description

As said by the title the goal is for any hack4impact directors to have the ability to sign into the memberDB tool automatically.
For some clarifications, we are using google sign-in as our method of integration. So see what ways we can accept a specific domain.

Learning objectives

• GAuth Development

Migrate member info from previous semesters to the atlas DB.
Previous Semester

Set up auth backend using Passport.js & Google OAuth
Examples:

• LAH
• Recruitment Portal

• PUT /member/:memberId
• Needs Auth (logged in & role protection)
• Member can only edit their own fields (A-K)
• Director can edit everything

GET /notes/labels

Return all unique note labels in the DB.

Description

There are two new fields that we think would help give an additional data point about every member.

• Slack Username
• Roles in the past (Role History)

Todo

These points are a rough guideline. Please feel free to discuss with others on the team about the best way to design this component!

• Specifically, add these only to the backend schema don't worry about frontend
• Test with your preferred platform (like postman) but make sure that add members, edit members, get members function well

GET /members/:memberId

Currently the viewableBy field is the sole determiner of whether or not a user can see a note. Lets change this so that individuals on the editableBy field are able to view a note by default.

Describe the bug
When clicking Create Note there is a delay before the button updates to Update Note. In the time of that delay, you can click Create Note again to create another instance of the same note.

Add a notes section to the Member DB schema.
DB Fields:

• String content
• Metadata
  • String title
  • String[] labels
  • MemberID[] referencedMembers
  • Object[] VersionHistory
    • MemberID actionBy
    • Date date
    • String action (Enum ["CREATE", "EDIT", etc.])
  • Access
    • MemberID[] viewableBy
    • MemberID[] editableBy

Features that notes must have according to PRD

• Allow directors to set visibility of note by selecting from list of members
• Track who edited it
• Set scopes of who can view note
• Add titles for notes

Describe the bug
You can create notes that you can't see if you forget to add yourself to the editors list.

To Reproduce
Steps to reproduce the behavior:

1. Create a note without adding yourself to the viewers

Expected behavior
You should be able to see the note 😛

Easy Fix

In ./client/src/pages/note.js push the current memberId onto the 'editableBy' list if the member did not add themselves.

Bonus Points

Filter the current member out of the options list for ease of use.

LAH User Schema

Update the list of fields editable by members on the backend.

https://www.ag-grid.com

Describe the bug
Users who are only viewers are presented with a form when viewing a note.

To Reproduce
Steps to reproduce the behavior:

1. Go to a note for which you are a viewer

Expected behavior
The form is greyed out or displayed in text

Quick Fix

Frontend

Add greyed/viewer state (quick win)
We could just see if the editableBy includes the current user. This is not the best solution, keep reading for the full-stack solution.

Optional Better Fix

Backend

Return the current member's permission level as part of the response note object.

Make member grid display data from mongo database and limit the scope to the member's role.

Relevant Files:

• client/src/components/table/Table.js
• client/src/utils/apiWrapper.js

Tasks:

• Hit /members endpoint from the frontend (write a new api call in apiWrapper.js to populate grid with user's viewable db data
• Use api call in Table.js and set result to members state variable

Describe the bug
Opening a link outside of home (e.g. https://members.h4i.app/notes) without logging in first results in an indefinitely loading page.

To Reproduce

1. Clear cookies for members.h4i.app
2. Navigate to members.h4i.app/notes

Expected behavior
App should redirect to members.h4i.app/login

Screenshots

Add a frontend route /notes. This should display an ag-grid table of all notes a user can view (handled by the backend).

We should put a "view notes" button on the profile page that redirects to /notes?memberID=. The ag-grid should filter to notes where referencedMembers includes memberID.

When a note is clicked on, redirect the member to /notes/:noteID. This page will be handled in another issue.

Add a button on the /notes page to create a new note. Look into using draft.js or markdown draft.js.

Ask Yousef

Break it up into two columns for less scrolling

In the schema, we store a lot of specific data fields as strings (for example, phone, email). We should do some validation on the frontend and backend to make sure our data is uniform. I.e. "Phone numbers must be of format xxx-xxx-xxxx"

The homepage table doesn't display many fields that it should be getting from the backend (netID, grad Sem/Year, etc.). It should be pretty straightforward to fix this by parsing the response from the backend and feeding it the table.

Dockerize Project

• Create docker_compose.yml
• Dockerfiles for api and client

Description

Add members should be moved to its designated location button instead of at the top of the page. This also relies on #101 and #102 Where there is a new component to input member information. Add Members functionality is already implemented you just need to marry both new designs together.

Add members are only available to Directors, so make sure to make yourself as a Director

Useful Resources

• Add User UI PR This should be useful to understand the functionality

GET /notes

• Return all viewable notes for the logged in user
• Return only metadata (compute fields such as last edited, and remove access field)

POST /notes

• Create a new note
• Check lead level

PUT /notes/:noteID

• Update note
• Check editableBy

DELETE /notes/:noteID

• Check editableBy

For all endpoints, ADMIN level takes precedence over editableBy/viewableBy

Create a modal on the /members page for adding members to the DB.
User should enter level/email for each user

Make request to /members/{current_member_id}/permissions. Only display this button if the endpoint returns "addMember".

• Migrate bridge components and styling to semantic ui react (frontend)
• Create new member modal (frontend)
• Add new member to db only if permission allows (backend)

• GET /members

Description

Currently, we are using AG Grid as a method of displaying member information and it is very straightforward in how it displays it. However, we want to make it more user-friendly and up to date with current h4i UI/UX trends

This is a high impact issue since it will be the first component members will be seeing and it will be used in many ways instead of just member info

Important: This is only focused on the look of the component. Don't worry too much about filters, add members or search members. But still, design this component in a way that those features can easily be implemented (ex. non-functional btns)

Learning objectives

• Craft highly malleable components
• Usage of CSS Grid based features

Todo

These points are a rough guideline. Please feel free to discuss with others on the team about the best way to design this component!

• Refer to the design scroll through and you'll see how buttons work to get a reference (no need to implement btn functionality)
• Explore different libraries that handle data display if AG Grid is not a good tool
• Implement table/grid UI
• Connect to API endpoints that already exist

Useful links

• https://www.ag-grid.com/react-grid/
• https://semantic-ui.com/

Description

Create endpoints that will support flexible schemas for non-required fields and toggle their visibility (e.g. director can add a field called “areDuesPaid” which is or isn’t visible to members of their chapter)

Things to consider:

• This is not only limited to the member schema, to ensure the highest code quality we want it to be versatile to other schemas that might exist like chapters and projects
• Due to the optional nature of new fields we won't have issues if fields don't exist in all documents
• Frontend needs to know the new fields so that they can be displayed
• All-new optional fields must contain a viewable field within (view permissions)
• Even though this is backend only while developing think of the frontend implementation too. This might save you from unnecessary endpoints or headaches

Learning objectives

• MongoDB usage and its features

Todo

These points are a rough guideline. Please feel free to discuss with others on the team about the best way to design this component!

• Brainstorm methods of storing new optional fields made by admins (maybe a new schema?)
• Brainstorm endpoints that will be useful for the frontend to know
• Look over ../models/members.js and linked related question
• Implement endpoints in ../src/api/ folder
• Test using Postman

Useful links

• https://stackoverflow.com/questions/7714216/add-new-field-to-every-document-in-a-mongodb-collection

Users are currently able to edit fields about a member's info on the frontend (provided they have proper permissions). Add a button to the Profile page that makes a PUT request to update the member's data after changes are made on the frontend.

For components, use H4I Bridge

Use the PUT /members/:memberID endpoint