buupe / inquisitor Goto Github PK

In the future it'd be nice to be able to work on the site and not worry about messing up actual user's data. To do so, we need a staging environment. Will require adding back the develop branch, which will essentially be the pre-release version of inquisitor. Branches will be made off develop and merged back into develop, and when it's time for a release a PR from develop to master will occur to bring in new features.

• Bring back develop branch, setup branch protections, update contributing guidelines
• Whenever a push/PR to develop happens, deploy to firebase hosting (master will continue to use gh-pages as the production hosting location)
• To differentiate data, create another firebase project (import production to seed it). Inject the firebase config using env variables locally, and through github secrets/actions (just compress the config into a json string so its one var). Load the appropriate var based on whether its develop or master branch, then deploy

This way we can have a staging environment in which we can mess with data as much as we want without fear of accidentally deleting real user data. Will need more rigorous code review when pulling into master to make sure stuff doesn't break existing data.

Add Redux to the application so that there exists a global state. A lot of our components share information so this will reduce the headache of passing down information to child components. This will also make it easy to save interview notes all at once (#2) since the app will know about all state at all times.

• Public User Pages
  • Signup Form
  • Unsubscribe Form
• Admin Page
  • SendGrid Re-Direct

Documentation from SendGrid API:

• Create Recipients: https://sendgrid.com/docs/API_Reference/Web_API_v3/Marketing_Campaigns/contactdb.html#Add-Single-Recipient-POST
• Add Recipient to a list: https://sendgrid.com/docs/API_Reference/Web_API_v3/Marketing_Campaigns/contactdb.html#Add-a-Single-Recipient-to-a-List-POST
• Contacts API: https://sendgrid.com/docs/API_Reference/Web_API_v3/Marketing_Campaigns/contactdb.html

Upon further research into the SendGrid API, it might actually be a good idea to create a dedicated email portal that allows UPE Admins & EBoard to directly manage and produce emails without touching the SendGrid page, but for now, and in an effort to not try to replicate the entire SendGrid build tool, for now, I'll have an admin page that re-directs to sendgrid

Instead of having individual save buttons for each question, have the submit button (or closing the application prematurely) save everything to the database. Perhaps including a timer that auto-saves every 5 minutes may be useful, or perhaps save whenever an input loses focus (the latter may be too many saves, not sure on the performance hit). This will be made easier by implementing global state with Redux (#14).

When a new interview starts, the interviewee picks up where the last one started

• Make prettier only write to staged files
• Have eslint warnings prevent commit

Tried this before and it caused the app to lag severely, perhaps there are better implementations to try now

• Have autocomplete for major and minor.
• year of graduation is a drop down (cur year plus 7)
• add deeper question config (support drop downs, word min max etc)

Need to wrap set interval in a use effect hook with value of timer as dep. Make sure to clear interval on unmount, and set state can take a function that modifies current value

• Have a pages folder where full pages (such as Apply, Create, etc.) live, and have the components folder hold only components.~~
• Move static assets into an S3 bucket to improve slug size

Replace Firebase with PostgreSQL. For our purposes, there's no real reason to do so, but using PostgreSQL will be a good learning opportunity as SQL is used extensively in the real world. To accomplish this, we'll make use of the node-postgres ORM, and we'll use a PostgreSQL instance from Heroku.

• Get Spark/someone to provide a credit card to file for UPE Heroku account
• Transfer ownership of Heroku project to UPE account
• Add PostgreSQL connector

Switch the generalSettings.js to use immutability helper to set values

Scope settings ie

{
  general: {}.
  timeslots: {},
  ...
}

Abstract rendering of settings so the file isnt huge

Use Prettier to enforce code style. Use pretty-quick to automatically apply them instead of annoying people.

Try looking up how to implement Firepad in React, see if it's viable. Ask a maintainer how it affects usage quota.

Otherwise just use Draft.js to make a text field for each interviewer (they only see they their own values, might be better that way)

Create a page that will allow taking attendance of candidates at recruitment events. This can just be a simple form of name, year, email, major, etc. Use preloading, such that if a candidate came to a previous event and starts typing their name, it should pop up and they can just prefill their information. Similarly, when applying, if a user exists from a recruitment event, pull their information to prefill some of the form.

Tasks

• Page condition: must have have recruitmentteam role
• If user is an Admin, they have option to open/close deliberations (if closed it should tell members that deliberations aren't happening right now). Will want to add a listener so if someone is on the page and an admin opens it, theyll update accordingly
• On page init do 2 things: 1) Use a transaction to increment number of active users viewing deliberation (also add a willUnmount that decrements, make sure the decrement works, will probably have to add cases for window before unload etc). 2) Get list of interviews (make sure to store id as well as data) Outdated
• Compute summary statistics (average question scores by level, by grad year) (look at the last seasons slides as reference for statistics) We could even do summary stats per question per level (i.e. average score for question id X in level Y, or grad year Z)
• Sort them according to some criteria (level? graduation year?). Have some sidebar that everyone can see that shows the order of people to vote on, and current person (so people know where they are/how many people are left)
• For each interview, fetch applicant info (all in their application) and display it (resume too since each person can be on this page and read at their pace). Display interviewer names. Display average question score of applicant along with summary stats for comparison. Display interviewer notes
• Admins can see sidepanel that lets them start a vote for the current applicant. Show number of users who's voted out of total users viewing
• Admins can then press a button to end the vote (hopefully they do it after everyone votes), and move on to the next person (should we show results right after a vote, or only until after all votes?)
• Results emails should tell people results in the email (instead of a link that takes them to the app to see results). If they got in, system should automatically convert all their user accounts to member accounts (remove nonmember role and add upemember role). Perhaps the congrats email can have a link to the main site profile page so people can check out their profile and edit it (does the main site allow them to upload their own pictures? Would ease work of admins, just tell people to upload professional images. In future seasons when you can meet in person, just tell them to update the images with the initiation photos when they get them. can distribute photos via google drive team)
• Once everything's over, and people see results, admins can close deliberations and this will send out results to applicants (either send results immediately, or schedule them to send at a specific time)
• For people who are rejected, remove the applicant role from them (don't worry about deleting applications/timeslots etc, as when next season starts you can just press the delete inquisitor data button to clear all that).

Stretch Goals

• Use google drive API and GitHub API (and any else we need) + Firebase Functions to automatically add new members to our team drive and github. We can ask them for a github/require they have one to apply so we have their username to do so (as cs kids they'll all have one eventually so might as well make it a requirement)

Data that will be needed:

• deliberations open/closed flag
• count of users viewing the deliberations page <- gotta make sure this is accurate for all cases (navigating away, closing page, reloading, etc)
• count of votes per applicant to determine results
• current applicant being viewed

Data that will exist (make dummy data for now)

• levelConfig (defines questions in a level, there will be a separate questions collection that holds all the questions and are pulled during interview session)

{ // levels are keys
  Easy: [
    {
      id: QUESTION ID, // id of the question to grab
      order: ORDER # // where to order it
    },
    ...
  ],
  Medium: [
    {
      id: QUESTION ID,
      order: ORDER #
    },
    ...
  ],
  Hard: [
    {
      id: QUESTION ID,
      order: ORDER #
    },
    ...
  ],
  ...
}

• interviews

{
  interviewers: {
    interview1UID: NAME VALUE,
    interview2UID: NAME VALUE
  },
  applicant: {
    uid: UID VALUE,
    name: NAME VALUE
  },
  level: LEVEL VALUE,
  scores: { // resume and final notes will be "questions" so theyll be here, score will be something like "N/A" or some value that we ignore for stats
    interview1UID: {
      question1Id: SCORE VALUE,
      question2Id: SCORE VALUE,
      ...
    },
    interview2UID: {
      question1Id: SCORE VALUE,
      question2Id: SCORE VALUE,
      ...
    }
  },
  notes: { // resume and final notes will be "questions" so theyll be here
    interview1UID: {
      question1Id: NOTES VALUE,
      question2Id: NOTES VALUE,
      ...
    },
    interview2UID: {
      question1Id: NOTES VALUE,
      question2Id: NOTES VALUE,
      ...
    }
  }
}

• applications

{
  responses: [ // can hard code grabbing of name, grad year, major/minor, resume since those ids will never change
    {
      id: application question id,
      name: application question name,
      order: order it appeared in application,
      type: type of question,
      value: Value user gave for question
    },
    ...
  ],
  semester: Semester-Year of this application
}

Tasks:

• Generalize the QuestionNotes component (#19) to work with the following (make sure they now work with the new format of questions that are stored in Firebase, will need to mock data until other PRs are closed):
  • Overview
  • Resume
  • Submit
• Load interview room automatically (use room,js in /pages, so url will be upe.bu.edu/interview/room)
  • Timeslot will have interviewer info, applicant info, and level. Use this to initialize the room automatically
  • When an interviewer loads the page, show them all the timeslots they are a part of for that day. They can hop in a room early and chill there
  • Once the timeslot time arrives, the interviewer can start the session (don't start automatically in case they're prepping/talking)
  • When an applicant loads the page, it won't let them in until the interviewer starts it (tell them the session hasn't started yet)
• Use Stopwatch.js (shown only to interviewers) so they can keep track of time
• Replace socket.io with Firebase to keep track of which question applicant is on. Create something like data/currentQuestion and store a doc that has the applicants current question id, and the interviewers can subscribe to that doc for changes (dont put it inside another doc because thats more unnecessary data, try to keep subscription to just what you need)
• Complete related tasks:
  • #2
  • #5
  • #19
• Delete when the above are done (as they'll no longer be needed):
  • StartScreen.js
  • JoinRoom.js

Change the buttons in navbar to only show to users who have access to it

DB Schema

/
- /users
- /uids
- /events
- /inquisitor
-- applicationFormConfig
-- generalSettings
--/data
----/applications
----/timeslots

Timeslot Doc Example

{
  time: Date
  interviewers: {
    uid1: true, // change this to the interviewer name so we can use it later
    uid2: true
  },
  applicant: {
    uid,
    name
  },
  timeslotLength
}

Tasks

• Port to Gatsby
• Admin page to configure application (use this)
• Add toggle next to questions to make them required or not
• Add deeper question config, like max/min words for textareas, acceptable file types for files, etc (modal probably on edit question) will wait till this is requested
• If applications exist, warn admins against editing application config
• Hook up emails
• Delete inquisitor collection button (includes download of backup and an import button, will probably need some functions) add this later
• Add reset buttons for settings that force default use
• Client page to apply
• prior to login save user route, so after login send them back there
• Refreshing apply page sometimes gets stuck loading forever
• Prune unused dependencies after (socket.io, react router, dotenv, express, lodash, mixin, moment)
• Warn users if they are going add/remove roles like admin/eboard
• Merge all the stuff in src/util/api with Firebase this will come during interview refactor
• Make sure the pathname saving works under the prefix path
• warn when user tries to navigate before saving (proof of concept in GeneralSettings.js)
• Add applicant timeslot page
• Allow adding in bonus timeslots in admin menu (for edge cases where we have to negotiate a timeslot)
• Allow shifting interviewers/interviewees around for timeslots (admin panel)
• Add validate rules for applicationConfig/generalSettings
• Add workflow for deploying on push to master
• Update documentation (readme and contributing) use https://www.gatsbyjs.org/tutorial/writing-documentation-with-docz/ docz doesn't make sense here, this isn't a component library
• add error boundary to layout to catch random errors
• Pull in name and email for application page
• replace all instances of firebaseinit state with class variable like in withAuthentication (faster)
• Move withAuth condition inside admin components instead of on page
• safe set state for with authentication
• Create simple flex div since you use it so often
• isLoggedIn doesnt force user to log in, instead tells them they dont have permission need to fix
• Applicationform needs to replace alert with swal
• Permission issue on timeslots page
• Manage users, cancel should reset state (it changes in background)
• Remove instances of passing the location prop to a page. Used originally for savePathname() to know the right path, but now we just use the useLocation hook, so passing the location prop is unnecessary

Keep in mind these are conducted virtually now, so have some sort of location option for timeslots that can be emailed to users (zoom rooms, or an address, etc). If its zoom, see if theres an integration to generate links

Currently interviewers have to fill in a candidate's information on creating an interview, however if a candidate applied through this application we have their information already. Refactor the component to load candidates from the database, filtering to show only the ones who should be there for that timeslot. This will have to wait until #6 and #8 are completed.

Detail how to implement pages properly, quirks specific to this project, etc

Generalize the component to allow the Overview, Resume, and Submit tabs to work. Also convert the component to a class to simplify state and effects.

Dealt with this before for QuaranteenU, just need to check the fix again. Low priority because people applying probably won't hit the unsubscribe button.

@BUUPE/eboard Please review emails for wording

Not a big deal as it's a warning during build and doesn't break the app. Likely due to the webpack config of our React Components.

Change Form.File type in the QuestionDisplay form to be a custom type Form.File instead of the regular one as to match the file upload style present in the application.

• Add applicant timeslot page
  • Allow people to change their selections if availability exists
  • Send confirmation emails to applicants
  • Make sure they only ever edit stuff they're a part of/empty. Use security rules to enforce this as well
• Refactor interviewer view: instead of selecting multiple and then saving all at once, save immediately on click.¹
• Allow adding in bonus timeslots in admin menu (for edge cases where we have to negotiate a timeslot)
• Allow shifting interviewers/interviewees around for timeslots (admin panel)
• Rename selectedTimeslots to timeslots in interviewer view
• On hover show full timeslot block (will need to convert to styled component)
• Cover case where there are timeslots with applicants and no interviewers (show as yellow in interviewer panel, maybe use yellow for open slots as well, should prioritize applicants with no interviewer so use a diff colorl)
• Add admin button to send email that timeslot selection is open/closed (for interviewers and for applicants separately)

[1] Trades efficiency of write operations for allowing interviewers greater control over selecting their slot. Currently interviewers can just pick times and the saving logic throws them into whatever slot it can. This way will allow users to pick a slot based on who's in it. When a user clicks a time, if there exists openings in existing slots, show them the existing times in a popup, with the option to create a new one. If there are no openings in a slot, act as if no one has selected (white box)

Currently all the questions are stored in /src/config, which isn't a good place to store them (nor are they actually application configuration variables). Moving them to a database will make them more secure since they won't be checked into this repository, and easier to keep track of.

• Move all questions into firebase: /inquisitor/data/questions
• Create admin panel to create/update/delete questions, as well as create/update/delete interview levels (a level is an ordered list of questions)

At the moment we don't have enough questions to be able to randomly generate question sets for levels, but keep that idea in mind while developing as that is a long-term goal (i.e. develop this in a way that would make random sets easy to integrate in the future)

Currently candidates apply through a Google Form that is made each semester. This should become a page within Inquisitor. It will essentially be the same form, but now we can save candidate information to our database right when they apply, making it easy to auto fill information when conducting interviews.

Create a publicly accessible page that allows users to practice on old questions. Allow users to select a level and then randomly generate an "interview" out of questions from that level. This way potential candidates can get a feel for the questions they might be asked (only select questions that are marked as public to prevent leaking of current interview questions, these questions can be marked through the admin interface in #20).

This task is low priority and requires the following tasks to be completed first:

• #4
• #8
• #20

When a user refreshes the page/application, any question notes/scores that have been saved should be displayed in the interface. However, notes/scores on the submit page don't repopulate when they should.

Wait to do this until #8 is completed.

Change current styling of levelDisplay Card to be bigger (set max width not actual width)

https://github.com/tannerlinsley/react-table

• Pages like manage users, etc. add in ability for sorting and filtering as eventually that list of names is gonna get huge (add more columns to sort/filter by, like year, class, etc)

Make it so if the list of question for a specific level passes a certain point it begins scrolling through it.

Create functions on the server using the SendGrid API to send emails. These emails can include application received receipts, timeslot confirmations, accepted/rejected results, etc. UPE has a SendGrid account, ask @ROODAY for an API key.

Change addQuestion in Level Display to be a modal that allows for multi question selection instead of single selection/confirmation

• Show breakdown of majors and class year
• in question config add flag for summary (those with flag will show up in statistics)

Averages by year, level, interviewer etc. have ways to mark if a person did a question. Get rid of bonuses.

Create an interface for authenticated users (E-Board or other allowed roles) to make configuration changes to the application. This will include editing questions, assigning questions to interview levels, setting their order, editing permissions for who can be an interviewer/see the admin panel, etc.

Currently timeslots for interviews are assigned via a Google Spreadsheet. This should be contained within Inquisitor. Allow UPE members to select times when they are free, and show these as available timeslots for candidates to select from.

Improve the input fields in the application form to be smarter (ie: use conditions/booleans/etc..)

Rename file method for the Firebase storage API to userFile

Since view applications is under /admin, if recruitmentteam users click admin they'll get the auth failed component with no ability to navigate to the view applications page. Either move view applications under a different route or make some more complex routing logic.

Have pre-commit hooks to prevent commits if common issues exist, such as:

• Committing sensitive information (credentials, etc.)
• Improper code-style (not following .editorconfig, etc.)

Other checks may be included. Make sure there exists a command to quickly apply all fixes the pre-commit hooks suggest so it doesn't get too annoying.

Convert the navbar to use the component from react bootstrap:
https://react-bootstrap.github.io/components/navbar/

This way it will collapse on mobile instead of overflowing

Find a way to deal with deleting questions and removing them from the associated levels, preferably with no data duplication and without going through all levels.

Use Material UI's CSS in JS solution.

Then have IS&T host it permanently as a lambda/S3 combo

After all candidates have completed interviews, compile summary statistics (average score, standard deviation, etc.) Generate slides for each candidate that shows their information along with summary statistics, and allow editing of slides to add in information like application/interview highlights.

Also allow anonymous voting through this page to handle deliberations, the results of which will be deleted after acceptance/rejection emails are sent.

Using BU SSO will add a layer of legitimacy to the application, as well as make it easy to gather basic info about users without asking them to register for the application.

Will require the following:

• http://www.passportjs.org/
• https://www.npmjs.com/package/passport-saml
• https://cs-people.bu.edu/dharmesh/teaching/shibboleth/
• https://github.com/ritstudentgovernment/passport-saml-example