Implementation

User Architecture

The above image shows the Flask routing for clients (Candidates and guests). It shows the user experience flow from login to schedule to candidate info card and back. Several pages edit or access the Database:

• The register page edits the database by:
  • updating it with a hashed version of the user’s password.
• The login page access the database to:
  • check whether the entered password matches with the password stored in the database.
• The schedule page reads from the database to:
  • retrieve all events in the user’s Candidates’ Weekend
  • display essential information like the event’s name, location, start time, and end time.
• The candidate info page reads from the database to:
  • retrieve and render essential information about the user, like the user’s name, their individual interview time and location, group interview location, the model class they’re attending and the location of the model class, and their interviewers.
• The event info page reads from the database to:
  • retrieve and render additional information about the selected event, like images and links associated with the event and the description for the event.

Admin Architecture

The above image shows the Flask routing for admins (the Admissions office). It shows the user experience flow from login to schedule to the manager page, etc. Several pages edit or access the database:

• The add event page edits the database by:
  • creating a new document for the event in the collection of events, where the document id is the event’s name and the event’s Candidates’ Weekend number concatenated, and the fields within the document is all the information for the event.
• The add user(s) page edits the database by :
  • reading in an Excel file and adding users to the authentication and to the database. It creates a new document for each user in the collection of users, with the document id being the user ID inputted in the Excel file, and filling the field with values from the Excel file.
• The select user page reads:
  • the list of users from the database to create a list so that the admin can select the user they want to edit.
• The edit user page accesses from the database:
  • to populate the edit user form with all current information for a user.
• The edit user page edits the database:
  • If the admin decides to delete a user, then the corresponding document for the user is deleted.
  • If the admin changes any information for a user, the corresponding fields’ values are updated in the database.
• The select event page”
  • reads the list of events from the database to create a list so that the admin can select the user they want to edit.
• The edit event page:
  • reads from the database to populate the edit event form with all current information for an event.
  • If the admin decides to delete an event, then the corresponding document for the event is deleted.
  • If the admin duplicates an event, then a new document is created with the same information, its document id being the current event’s document id with the word ‘copy’ added to the end (to avoid duplicate document ids).
  • If the admin changes any information for an event, the corresponding fields’ values are updated in the database.
• The update CW form:
  • reads from the database to display the current Candidates’ Weekend number
  • changes the database if the current Candidates’ Weekend is changed.
• The admin schedule page:
  • reads from the database to pull all events for the current Candidates’ Weekend number and displaying essential information for each event, like the name, location, start time, and end time.
• The admin event info page:
  • pulls additional information for the each event from the database, like images and links associated with the event and the description for the event.

Database Structure

Events Collection

Special notes:

• There is a dummy document in the events collection that stores general information for all events. At the moment, the only information in the document is the current Candidates’ Weekend, but there could be additional information added (like default locations or a list of speakers, for example).
• In order to avoid multiple documents having the same ID, but still allowing for multiple events across multiple Candidates’ Weekends (and allowing for slight differences in events across Candidates’ Weekends), the document ID for an event has the event’s name and hyphenated additions if the event is a copy of another event and the Candidates’ Weekend number. When displaying the event, two methods are used.
  • get_raw_name takes in an event name and strips the Candidates’ Weekend number; this is used in the edit event form.
  • get_display_name takes in an event name and strips all additions (including the word “copy”); this is used in the schedule and in the additional event information pages.

Users Collection