From a029d0058680ad026855db4c9ba0efe3a7a1ea8f Mon Sep 17 00:00:00 2001
From: neetidesai <97416423+neetidesai@users.noreply.github.com>
Date: Sat, 22 Apr 2023 15:35:16 -0400
Subject: [PATCH 1/2] Add files via upload

Breaktime docs
---
 docs/breaktime/arcgis-architecture.md         | 495 ++++++++++++++++++
 docs/breaktime/breaktime-api-spec.md          | 128 +++++
 .../sftt-frontend-walkthrough.md              |  99 ++++
 .../breaktime/frontend-guides/sftt-routing.md | 295 +++++++++++
 docs/breaktime/index.md                       |  11 +
 5 files changed, 1028 insertions(+)
 create mode 100644 docs/breaktime/arcgis-architecture.md
 create mode 100644 docs/breaktime/breaktime-api-spec.md
 create mode 100644 docs/breaktime/frontend-guides/sftt-frontend-walkthrough.md
 create mode 100644 docs/breaktime/frontend-guides/sftt-routing.md
 create mode 100644 docs/breaktime/index.md

diff --git a/docs/breaktime/arcgis-architecture.md b/docs/breaktime/arcgis-architecture.md
new file mode 100644
index 0000000..11cf9e6
--- /dev/null
+++ b/docs/breaktime/arcgis-architecture.md
@@ -0,0 +1,495 @@
+# General Overview
+
+SFTT uses ArcGIS to handle the block location, shape, and reservation status. Block data is stored in an ArcGIS database. The reservation pages on the SFTT web application incorperate the ArcGIS JavaScript API: https://developers.arcgis.com/javascript/latest/guide/. User data is stored in a separate SFTT database.
+
+The component that represents the webpages with the map is the `MapContainerView`. Navigate to one of the map pages via the 'Reserve New Blocks' or 'Reservations Map' as a normal user or through the 'Active Blocks Map' as an admin. 'Reserve New Blocks' will display open blocks, 'Reservations Map' displays blocks the user has reserved, and 'Active Blocks Map' displays all reserved and completed blocks.
+
+The blocks that a user has reserved are stored in the SFTT database. Upon navigating to the 'Reservations Map', a get request for the user's reserved blocks is made. Then a query is made with these block IDs for the rest of the ArcGIS block data and the corresponding blocks are displayed on the map.
+
+The map itself is the `MapComponent`. This allows users to move around Boston and interact with the blocks from ArcGIS. The colored shapes represent blocks and the red lines represent private streets. The `MapComponent` also allows users to find their location and to toggle labels for the blocks.
+
+Clicking on of the colored blocks displays a popup with the information about a specific block, its ID and Reservation Status which is either open, reserved, or complete. Depending on the reservation status, a user is able to interact with blocks of different statuses in different ways. Clicking on one of the buttons in the bottom left corner of the popup adds it to a list of active blocks.
+
+These lists are available above the `MapComponent` in the `SelectedBlocks` component. A user can open the popver which displays the IDs of the currently selected blocks. Clicking the X on one of these blocks triggers a callback to the `MapContainerView` to remove that block from the selected list. Clicking the other button will trigger a Post request to the SFTT api to change the reservation status of each blocks in the active list. There are separate lists for reserving, releasing, and completing blocks.
+
+
+# Map router
+
+## Normal Routes 
+
+### `/reserve/:editmode`
+
+>editmode defaults to 'new' which routes to a MapContainerView with a map that displays blocks that are currently open (have not been reserved).
+
+>editmde can also be set to 'edit' which routes to MapContainerView with a map that displays the blocks that the user currently has reserved.
+
+>Can be passed activeBlockId as a prop which will highlight the block with the given ID.
+
+## Admin Routes
+
+### `/admin-map`
+
+>routes to a MapContainerView which displays all of the blocks that are currently reserved or completed by all users. Only accessible to users with ADMIN level privileges.
+
+# MapContainerView
+
+The routes to the map pages lead to the MapContainerView which acts as a container for the map component.
+
+
+## Props
+
+### `activeBlockId`
+
+```
+(Not Required)
+Type: String
+```
+
+>When entering the MapContainerView from one of the reservation list pages, the id of the selected block is highlighted
+
+## Data
+
+### `blocksToReserve, blocksToRelease, blocksToComplete`
+
+```
+Type: Array of Strings
+```
+
+>A pending list of the block IDs in JSON format that can be reserved, released, or completed upon clicking the buttons at the top of the map. These lists are passed to the `SelectedBlocks` component and displayed in a dropdown
+
+### `modalMessage, blockListString`
+
+```
+Type: String
+```
+
+>The message displayed in the modal after attempting to reserve, release, or complete a set of blocks
+
+### `showHeader`
+
+```
+Type: Boolean
+```
+
+>If true, the test header will be visable at the top of the page, if false, it will be collapsed
+
+## Computed
+
+### `isAdminMap`
+
+```
+Returns: Boolean
+```
+
+>Determines if this is an AdminMap depending on the route. Admin maps allow users to interact with all of the reserved and completed blocks, as opposed to the normal reservation maps which only allow users to interat with the blocks they reserved themselves.
+
+### `header`
+
+```
+Returns: {
+  headerVal: String,
+  subTitle: String
+}
+```
+
+>The header strings to appear at the top of the page. Changes depending on the route
+
+### `reservedFilter`
+
+```
+Returns: Number
+```
+
+>Determines the reservation status that the map will use as a filter depending on :editmode. returns 0 for 'new' and 1 for 'edit'
+
+## Methods
+
+### `pushBlock`
+
+```
+Inputs:
+block: string
+selection: 'reserve' | 'release' | 'complete'
+
+Returns: void
+```
+
+>Converts the given block ID to JSON and adds it to the pending reserve, release, or complete list depending on the given selection. If the given ID is already in one of the pending lists, displays an error message.
+
+### `reserveBlocks`
+
+```
+Inputs: None
+
+Returns: void
+```
+
+>Converts the `blocksToReserve` Array from data to a string. calls the reserveBlocks api function which makes a post request `/reserve` with the string of block ids as the body. 
+
+>If successful, resets `blocksToReserve` to an empty Array, displays a confirmation message, and refreshes the map to display the updated block statuses.
+
+>If unsuccessful, display a failure message.
+
+### `releaseBlocks, completeBlocks`
+
+>Identical behavior to reserveBlocks except the JSON lists are blocksToRelease, `blocksToComplete` and the api routes called are `/release`, `/complete`
+
+
+### `setReserveBlocks, setReleaseBlocks, setCompleteBlocks`
+
+```
+Inputs:
+blocks: Array of strings
+
+Returns: void
+```
+
+>Sets the corresponsing `blocksToReserve, blocksToRelease, blocksToComplete` list equal to the given blocks
+
+# mapConstants
+
+### `addToReserve, addToReserve, addToComplete`
+
+```
+Type: ActionButton (ArcGIS type)
+```
+
+>Each object represents one of the buttons on the `blockPopupTemplate`. Clicking on one of these buttons triggers an event which calls `pushBlock` with the appropriate selection.
+
+For more information on actions: https://developers.arcgis.com/javascript/latest/api-reference/esri-support-actions-ActionButton.html
+
+### `blockRenderer`
+
+```
+Type: Renderer (ArcGIS type)
+```
+
+>Tells the `blockLayer` how to display each of the blocks. Sets a different color for the different possible reservation statuses
+
+For more information on Renderers: https://developers.arcgis.com/javascript/latest/api-reference/esri-renderers-Renderer.html
+
+### `privateStreetRenderer`
+
+```
+Type: Renderer (ArcGIS type)
+```
+
+>Tells the `privateStreetLayer` how to display each of the private streets. Currently displays each street as a solid red line
+
+### `blockLabel`
+
+```
+Type: LabelClass (ArcGIS type)
+```
+
+>How the optional ID labels on the map will be displayed.
+
+For more information on LabelClasses: https://developers.arcgis.com/javascript/latest/api-reference/esri-layers-support-LabelClass.html
+
+# MapComponent
+
+ArcGIS types are lazy loaded in `loadMap` method.
+
+## Props
+
+
+### `reservedFilter`
+
+```
+Type: Number
+Required: false
+```
+
+>The Reservation status of blocks to be displayed on the map. 0 for open, 1 for reserved.
+
+### `pushBlock`
+
+```
+Type: Function
+
+Inputs:
+block: string
+selection: 'reserve' | 'release' | 'complete'
+
+Returns: void
+
+
+Required: false
+```
+
+>Callback from MapContainerView which adds the given block to one of the active block lists when an event from selecting one of the `blockActions` is triggered.
+
+### `activeBlockId`
+
+```
+Type: string
+
+Required: false
+```
+
+>The popup of the block with the `activeBlockId` will be open upon loading the map.
+
+### `isAdminMap`
+
+```
+Type: Boolean
+
+Required: false
+```
+
+>If true, all completed and reserved blocks will be displayed
+
+## Data
+
+### `labelsVisible`
+
+```
+Type: Boolean
+```
+
+>If true, the IDs of the blocks will be displayed on the map
+
+
+## Computed
+
+
+### `mapState`
+
+>Sets the `reservedBlocks` state to the user's reserved blocks from the VueX store.
+
+### `blockFilter`
+
+```
+Returns: String
+```
+
+>The 'where' clause of a query that determines which blocks will be displayed on the map depending on their reservation status. If somehow the mapview is accessed through none of the proper routes, the filter will ensure no blocks are displayed.
+
+### `blockPopupTemplate`
+
+```
+Returns: PopupTemplate (ArcGIS type)
+```
+
+>Contains the format of the popups that appear when clicking a block. Includes the ID, the resercation status, and a list of `blockAction`. Content displayed is determined by the contents of the selected feature (block). 
+
+For more information on PopupTemplates: https://developers.arcgis.com/javascript/latest/api-reference/esri-PopupTemplate.html
+
+
+### `blockActions`
+
+```
+Returns: Array of ActionButton (ArcGIS type)
+```
+
+>Determines which buttons will appear on the `blockPopupTemplate` depending on the `reservedFilter`.
+
+### `blockLayerObject`
+
+```
+Returns: FeatureLayer (ArcGIS type)
+```
+
+>Contains the block data from ArcGIS, the rules for displaying blocks, and the interactions users can have with the blocks. 
+
+>The `blockLayerObject` queries the ArcGIS database linked in the `url` field using the `blockFilter` as the WHERE clause. Each block is a feature.
+
+For more information on FeatureLayers: https://developers.arcgis.com/javascript/latest/api-reference/esri-layers-FeatureLayer.html
+
+### `privateStreetLayerObject`
+
+```
+Returns: FeatureLayer (ArcGIS type)
+```
+
+>Contains the private streets and the rules for displaying these streets on the map. Unlike with blocks there are no interactions available.
+
+
+## Methods
+
+
+### `showLabels`
+
+```
+Returns: void
+```
+
+> Changes `labelsVisible` from positive to negative and vice versa. Turns block labels on and off.
+
+### `reservationToString`
+
+```
+Input: Feature (ArcGIS type)
+
+Returns: string
+```
+
+>Converts the integer reservation status of a block as stored in ArcGIS to the correct string to be displayed in the popup. 0 -> Open, 1 -> Reserved, 2 -> Complete.
+
+### `loadMap`
+
+```
+Returns: void
+```
+
+>Uses lazy loading to load the necessarily JS modules from ArcGIS: ArcGISMap, MapView, FeatureLayer, Locate.
+
+>Initializes a blank map and a MapView. Mapview is the main container of all other map objects defined above. Adds the `blockLayerObject` and `privateStreetLayerObject` to the view. This allows the program to query for blocks from the ArcGIS database. 
+
+>The locate object allows users to have the map center over their current real world location.
+
+>There is an optional query after the map has loaded which finds the block associated with `activeBlockId` in the `blockLayer` and displays that block's popup.
+
+For more information on MapViews: https://developers.arcgis.com/javascript/latest/api-reference/esri-views-MapView.html
+
+## Mounted
+
+Dispatches to VueX store with `getReservedBlocks` to get blocks from the api.
+
+Calls `loadMap`.
+
+## Watch
+
+Calls `loadMap` when `reservedBlocks` changes, meaning once `reserveBlocks`, `releaseBlocks` or `completeBlocks` is called on the mapView. Map will now be displayed with the updated block reservation statuses.
+
+Calls `loadMap` when `reservedFilter` changes. Because SFFT has a single page application, the page does not reset when changing to a differnt route that displays a map. Because of this the map needs to be rerendered to updated the block filter.
+
+Calls `loadMap` when `labelsVisible` changes to account for updated labels.
+
+# `SelectedBlocks`
+
+A reusable component that takes a given list of block IDs. Users can view the list in a popover menu and have the option to remove the each individual ID from the list. There is also a button that allows users to trigger a call back. In this case the callback will activate one of the post requests from the `MapContainerComponent` with the list of block IDs.
+
+## Props
+
+### `onClick`
+
+```
+Type: Function
+
+Inputs: None
+
+Returns: Void
+```
+
+>A callback which is activated when clicking the button in the pending block popover. For the map this callback is `reserveBlocks`, `releaseBlocks`, or `completeBlocks`.
+
+### `blocks`
+
+```
+Type: Array of string
+```
+
+>List of block IDs that will appear in the popover.
+
+### `title`
+
+```
+Type: string
+```
+
+>The string to appear on the popover header and the popover button.
+
+### `setBlocks`
+
+```
+Type: Function
+
+Inputs: Array of string
+
+Returns: void
+```
+
+>Callback which is called In the `removeBlock` method. Sets the array passed in `blocks` prop to the given array.
+
+## Data
+
+### `popoverToggle`
+
+```
+Type: Boolean
+```
+
+>Indicates if user has selected to open the popover.
+
+## Computed
+
+### `displayPopover`
+
+```
+Returns: Boolean
+```
+
+>Checks if user has selected to open the popover and that there is at least one block in `blocks`.
+
+## Methods
+
+### `removeBlock`
+
+```
+Input: string
+
+Returns: void
+```
+
+>Removes the given block from `blocks` and then calls `setBlocks` with that array as an input.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/breaktime/breaktime-api-spec.md b/docs/breaktime/breaktime-api-spec.md
new file mode 100644
index 0000000..1c7d8f8
--- /dev/null
+++ b/docs/breaktime/breaktime-api-spec.md
@@ -0,0 +1,128 @@
+# Breaktime API Specification
+This is the official API specification for the Breaktime back end. The back end is implemented as is described in the documentation below and should correspond exactly with how the back end behaves. If you find any inconsistencies please create a PR to amend the error.
+
+
+## Enums
+
+### Privilege Level
+
+The privilege level enum is all the possible privilege levels a user can have. This is stored in the users table as the privilege_level field. The possible options are:
+
+I don’t think we have these yet, leaving this here as a placeholder
+
+### Team Role
+
+The team role enum is all the possible states a use can be in in relation to a team. This is stored in the users_teams table on the backend as the team_role field. The possible options are:
+
+I don’t think we have these yet, leaving this here as a placeholder.
+
+## Auth Router
+
+This router is used to authenticate users. It handles logins, logouts, signups but also things like resetting passwords and secret keys. All of these parts are public, as in users don't need to be authenticated yet to call these routes.
+
+### Login
+
+
+
+#### Request Body
+
+
+#### Responses
+
+##### `201 Created`
+
+
+##### `400 Bad Request`
+
+##### `401 Unauthorized`
+
+### Sign Up
+
+#### Request Body
+
+#### Responses
+
+##### `201 Created`
+ 
+##### `400 Bad Request`
+
+##### `409 Conflict`
+
+### Log Out
+
+
+#### Request Body
+
+
+#### Responses
+
+##### `204 No Content`
+
+### Refresh Access Token
+
+
+
+#### Request body
+
+
+#### Responses
+
+##### `201 Created`
+
+
+##### `401 Unauthorized`
+### Request Password Reset
+
+
+#### Request Body
+
+
+#### Responses
+
+##### `200 OK`
+
+
+##### `400 BAD REQUEST`
+
+
+
+## Timesheet
+
+Used to store a user’s timesheet data. A timesheet is defined as one week’s worth of timesheet entries, Sunday through Saturday. A unique timesheet is defined as a timesheet with a unique UserID and TimesheetID pair. There can be multiple timesheets per user.
+
+#### Request body
+
+```json
+{
+  "UserID": STRING,
+  "TimesheetID": STRING,
+  "Company": EMAIL,
+  "StartDate": NUM,
+  "Status": OBJECT,
+    "StatusType": STRING,
+    "SubmittedDate": NUM,
+  "WeekComments": ARRAY,
+      "Comment": OBJECT,
+        "Type": STRING,
+        "AuthorUUID": STRING,
+        "Timestamp": STRING,
+        "Content": STRING,
+  "TableData": ARRAY,
+      "StartDate": NUM,
+      "EndDate": NUM,
+      "Comment": OBJECT
+        "Type": STRING
+        "AuthorUUID": STRING,
+        "Timestamp": STRING,
+        "Content": STRING,
+      "Duration": NUM
+  "ScheduleTableData": ARRAY,
+      "ScheduleEntry": OBJECT,
+        "StartDate": NUM,
+        "Duration": STRING,
+    
+}
+```
+
+
+
diff --git a/docs/breaktime/frontend-guides/sftt-frontend-walkthrough.md b/docs/breaktime/frontend-guides/sftt-frontend-walkthrough.md
new file mode 100644
index 0000000..db8d6a7
--- /dev/null
+++ b/docs/breaktime/frontend-guides/sftt-frontend-walkthrough.md
@@ -0,0 +1,99 @@
+# Walkthrough
+
+A guide to the basic structure of the frontend.
+
+## :file_folder: public
+
+You _could_ add assets outside the module system here (things that won't be processed by 
+[webpack](https://webpack.js.org/concepts/)), but generally you'll just leave this folder alone.
+
+_For more information, see the 
+[Create React App Docs](https://create-react-app.dev/docs/using-the-public-folder)_.
+
+### :memo: index.html
+
+The base HTML file that the site is built off of. Here, you can set the page title (shown in the 
+browser's tab), and import fonts by adding links to stylesheets. Ultimately, a `<script>` tag with
+the compiled code will be added to this file automatically during the build process.
+
+### :memo: favicon.ico
+
+The icon displayed in the address bar of the browser.
+
+### :memo: manifest.json
+
+Specifies basic metadata about the application, such as its name and icons.
+
+### :memo: robots.txt
+
+Specifies what parts of the site web robots are allowed to crawl. We allow all web crawlers to 
+access all content. Note that web crawlers can ignore this file (it won't stop any malware).
+
+## :file_folder: src
+
+### :memo: App.tsx
+
+The central application component. In it, we handle [routing](../frontend-guides/sftt-routing.md). 
+That is, depending on the user's privilege level and what path the user wanted to go to, we decide 
+which container to render.
+
+### :memo: store.ts
+
+A Redux file where we create the application [store](https://redux.js.org/api/store), which holds 
+the state tree of the application. In this file, we declare relevant types (ex. `C4CState`), combine 
+our reducers, define our initial state, and apply thunk middleware.
+
+### :file_folder: api
+
+Contains the logic to access data from the backend. We use 
+[Axios](https://medium.com/@MinimalGhost/what-is-axios-js-and-why-should-i-care-7eb72b111dc0) to 
+make requests to our backend.
+
+_Axios documentation to be completed._
+
+#### :memo: apiClient.ts
+
+Contains the routes, types, and logic to create an `ApiClient` object, through which users can make 
+`PrivilegeLevel.NONE` requests to the backend.
+
+#### :memo: protectedApiClient.ts
+
+Contains the routes, types, and logic to create a `ProtectedApiClient` object, through which users 
+can make `PrivilegeLevel.STANDARD`, `PrivilegeLevel.ADMIN`, and `PrivilegeLevel.SUPER_ADMIN` 
+requests to the backend.
+
+### :file_folder: assets
+
+Contains image (under `images`) and text (within `content.tsx`) assets to be used throughout the 
+site.
+
+### :file_folder: auth
+
+Contains all logic related to the authentication system.
+
+#### :file_folder: [ducks](https://docs.c4cneu.com/guides/frontend-redux/)
+
+Contains all Redux ducks related to the authentication state of the application.
+
+#### :memo: authClient.tsx
+
+Contains the routes, types, and logic to create an `AuthClient` object, through which users can make
+auth-related requests (ex. login, logout) to the backend.
+
+#### :memo: axios.ts
+
+Creates the application `AxiosInstance` through which all clients make requests to the backend. 
+Contains logic related to adding authentication headers to requests and automatically refreshing 
+the authentication tokens.
+
+### :file_folder: components
+
+Contains presentational components that are reused across the application.
+
+### :file_folder: containers
+
+Contains each page–their layouts and related thunks and logic. 
+
+### :file_folder: utils
+
+Contains useful types, functions, and constants that are used throughout the application.
diff --git a/docs/breaktime/frontend-guides/sftt-routing.md b/docs/breaktime/frontend-guides/sftt-routing.md
new file mode 100644
index 0000000..7609b24
--- /dev/null
+++ b/docs/breaktime/frontend-guides/sftt-routing.md
@@ -0,0 +1,295 @@
+# Frontend Routing
+
+## The Basics
+Routing, essentially rendering the correct content for the current URL and user, primarily takes 
+place in the App component.
+
+Using [React Router](https://v5.reactrouter.com/web/guides/quick-start), we can render the correct 
+component for the current URL easily with the `Route` component:
+
+```html
+<Route path={Routes.LANDING} exact component={Landing} />
+```
+
+Here, if the application's path is `Routes.LANDING`, then `Route` will render the `Landing` 
+page. (If it isn't, it'll render null).
+
+Now consider a simplified version of our application with four declared paths. If we just had 
+four `Route`s, then if the URL matched more than one of those paths, we would render more 
+than one component. However, in our App, we only want to render one page at a time. To accomplish 
+this, we use React Router's `Switch` component:
+
+```html
+<Switch>
+  <Route path={Routes.LANDING} exact component={Landing} />
+  <Route path={Routes.LOGIN} exact component={Login} />
+  <Route path={Routes.HOME} exact component={Home} />
+  <Route path={Routes.ADMIN} exact component={AdminDashboard} />
+</Switch>
+```
+
+`Switch` looks for a `Route` that matches the current path (in top-down order), then renders its 
+component and nothing else.
+
+## Auth Redirects
+
+So far, so good. However, a user who isn't logged in shouldn't be able to go to the home page. 
+Similarly, only admin users should have access to the admin dashboard. How can we ensure 
+that users go to the appropriate pages based on their privilege level?
+
+First, we have to get the user's privilege level using our [Redux selector](https://docs.c4cneu.com/guides/frontend-redux/).
+
+```ts
+const privilegeLevel: PrivilegeLevel = useSelector((state: C4CState) => {
+    return getPrivilegeLevel(state.authenticationState.tokens);
+  });
+```
+
+Then, we just use a switch statement to return the correct `Switch` and `Route`s.
+
+```ts
+switch (privilegeLevel) {
+  case PrivilegeLevel.NONE:
+    return (
+      // routes for a user who isn't logged in  
+    );
+  case PrivilegeLevel.STANDARD:
+    return (
+      // routes for a standard logged-in user  
+    );
+  case PrivilegeLevel.ADMIN:
+  case PrivilegeLevel.SUPER_ADMIN:
+    return (
+      // routes for admins  
+    );
+}
+```
+
+What do the routes actually look like?
+
+Let's start with the user that isn't logged in. This user should be able to go to the Landing and 
+Login pages, but not the Home or Admin Dashboard pages. If they try to go to either of these pages, 
+we should redirect them to the Login page. Luckily for us, React Router has a `Redirect` component 
+too. So we have:
+
+```html
+<Switch>
+  <Route path={Routes.LANDING} exact component={Landing} />
+  <Route path={Routes.LOGIN} exact component={Login} />
+  <Redirect from={Routes.HOME} to={Routes.LOGIN} />
+  <Redirect from={Routes.ADMIN} to={Routes.LOGIN} />
+</Switch>
+```
+
+If a user tries to go to the home page, we'll redirect them to `Routes.LOGIN` and our second
+`Route` component will render the `Login` page.
+
+### Redirecting Back After Login
+
+But wouldn't it be great if we could send the user back to the page they originally wanted to go to 
+after they log in? Well, we can do that with React Router's `location`, which represents "where the 
+app is now, where you want it to go, or even where it was" (according to the docs). Instead of 
+passing `Redirect`'s `to` parameter a string (`Routes.LOGIN`), we can pass it a location.
+
+Then, instead of
+```html
+<Redirect from={Routes.HOME} to={Routes.LOGIN} />
+```
+
+we'll have
+
+```html
+<Redirect 
+    from={Routes.HOME} 
+    to={{
+      pathname: Routes.LOGIN, 
+      state: {
+        destination: ROUTES.HOME,
+      },
+    }}
+/>
+```
+
+so the user will still go to `Routes.LOGIN`, but our Login page will be able to access this `state` 
+property and learn that the user wanted to go `Routes.HOME`. 
+
+We can abstract this `Redirect` with location logic into a component that we'll call
+`AuthRedirect`:
+
+```tsx
+interface AuthRedirectProps {
+  readonly from: string;
+}
+
+const AuthRedirect: React.FC<AuthRedirectProps> = ({ from }) => {
+  return (
+    <Redirect
+      from={from}
+      to={{
+        pathname: Routes.LOGIN,
+        state: {
+          destination: from,
+        },
+      }}
+    />
+  );
+};
+```
+
+!!! note
+    
+    `location.state` can have any props. We decided to name our redirect prop `destination`, which 
+    we declare in  the following interface (located in App):
+    ```ts
+    interface RedirectStateProps {
+      readonly destination: Routes;
+    }
+    ```
+
+Then, after the user logs in, we can redirect the user to the home page.
+
+```ts
+// in the Login container
+
+// get the location, which has RedirectStateProps
+const location = useLocation<RedirectStateProps>(); 
+
+// if the user was redirected
+const destination: Routes = location.state
+    // get where they originally wanted to go (for us, Routes.Home)
+    ? location.state.destination
+    // otherwise, redirect them to Home after login (which is where we wanted to go anyway!)
+    : Routes.HOME;
+
+if (loggedIn) {
+  // redirect user to home page
+  return <Redirect to = {'/' + query.get('destination')}/>;
+} else {
+  return <LoginPage />;
+}
+```
+
+and finally, for our `PrivilegeLevel.NONE` user we have:
+
+```html
+case PrivilegeLevel.NONE:
+  return (
+      <Switch>
+          <Route path={Routes.LANDING} exact component={Landing} />
+          <Route path={Routes.LOGIN} exact component={Login} />
+          <AuthRedirect from={Routes.HOME} />
+          <AuthRedirect from={Routes.ADMIN} />
+      </Switch>
+  );
+```
+
+!!! note
+
+    There are other ways to do this, namely by using path parameters and/or query parameters.
+    For instance, instead of having our `AuthRedirect`, we could do something like:
+
+    ```html
+    <Redirect from={Routes.HOME} to={Routes.LOGIN + '?destination=home'} />
+    ```
+
+    Then in `Login`, we'd do something like:
+
+    ```ts
+    // in the Login container
+    const history = useHistory(); // get the browser's history
+    const location = useLocation(); // get the location
+
+    // get the query parameters
+    const query: = new URLSearchParams(location.search);
+    
+    if (loggedIn) {
+      // redirect the user to the desired destination
+      return <Redirect to={'/' + query.get('destination')} />;
+    }
+    ```
+
+    **Why use this way?**
+    
+    The primary reason is that `location` isn't shared across different tabs/browsers. So if you 
+    open a new Login tab, the app won't redirect you to your original destination. But if you 
+    open a new Login tab with the same query param (which you would get if you copy/pasted the 
+    link), it will.
+
+    **The catch**
+
+    Users have access to the URL–they can mess with the query params and break things. Also, 
+    people tend to copy URLs directly when they share them, meaning they tend to share the query 
+    params. That's fine in some cases, but not when you don't want to share the query param behavior 
+    across any two random users.
+
+## Finishing up App
+
+Just a little more to go! Thankfully, our standard and admin-level routing is pretty straightforward: 
+
+Standard users are redirected from the Admin Dashboard to Home:
+```html
+<Switch>
+  <Route path={Routes.LANDING} exact component={Landing} />
+  <Route path={Routes.LOGIN} exact component={Login} />
+  <Route path={Routes.HOME} exact component={Home} />
+  <Redirect from={Routes.ADMIN} to={Routes.HOME} />
+</Switch>
+```
+
+and admins can go anywhere:
+```html
+<Switch>
+  <Route path={Routes.LANDING} exact component={Landing} />
+  <Route path={Routes.LOGIN} exact component={Login} />
+  <Route path={Routes.HOME} exact component={Home} />
+  <Route path={Routes.ADMIN} exact component={AdminDashboard} />
+</Switch>
+```
+
+Then we just throw it all into React Router's `BrowserRouter` component that syncs the 
+application to the browser's URL and put everything in App!
+
+```tsx
+const App: React.FC = () => {
+  const privilegeLevel: PrivilegeLevel = useSelector((state: C4CState) => {
+    return getPrivilegeLevel(state.authenticationState.tokens);
+  });
+
+  return (
+  <BrowserRouter>
+    {(() => {
+      switch (privilegeLevel) {
+        case PrivilegeLevel.NONE:
+          return (
+            <Switch>
+              <Route path={Routes.LANDING} exact component={Landing} />
+              <Route path={Routes.LOGIN} exact component={Login} />
+              <AuthRedirect from={Routes.HOME} />
+              <AuthRedirect from={Routes.ADMIN} />
+            </Switch>
+          );
+        case PrivilegeLevel.STANDARD:
+          return (
+            <Switch>
+              <Route path={Routes.LANDING} exact component={Landing} />
+              <Route path={Routes.LOGIN} exact component={Login} />
+              <Route path={Routes.HOME} exact component={Home} />
+              <Redirect from={Routes.ADMIN} to={Routes.HOME} />
+            </Switch>
+          );
+        case PrivilegeLevel.SUPER_ADMIN:
+        case PrivilegeLevel.ADMIN:
+          return (
+            <Switch>
+              <Route path={Routes.LANDING} exact component={Landing} />
+              <Route path={Routes.LOGIN} exact component={Login} />
+              <Route path={Routes.HOME} exact component={Home} />
+              <Route path={Routes.ADMIN} exact component={AdminDashboard} />
+            </Switch>
+          );
+      }
+    })()}
+  </BrowserRouter>
+  );
+};
+```
diff --git a/docs/breaktime/index.md b/docs/breaktime/index.md
new file mode 100644
index 0000000..2141b0c
--- /dev/null
+++ b/docs/breaktime/index.md
@@ -0,0 +1,11 @@
+# Breaktime
+
+In this section you will find all the developer documentation related to our Breaktime project.
+
+## [API Specification](./breaktime-api-spec)
+
+The full API specification for our backend. This page lists every backend route and describes what it does, the request body and the possible responses. 
+
+## [(DEPRICATED) ArcGIS Map Documentation](./arcgis-architecture.md)
+
+A thorough description of our legacy ArcGIS map technology. This has since been replaced by the Google Maps API.

From 1c706b79b8aa50becb9b212935291c76bc06a217 Mon Sep 17 00:00:00 2001
From: Neeti <desai.ne@northeastern.edu>
Date: Sun, 25 Jun 2023 23:14:43 -0400
Subject: [PATCH 2/2] Updated database table documentation

---
 docs/breaktime/breaktime-api-spec.md | 227 +++++++++++++++++++++++++++
 docs/breaktime/index.md              |   7 +
 mkdocs.yml                           |   3 +
 3 files changed, 237 insertions(+)
 create mode 100644 docs/breaktime/breaktime-api-spec.md
 create mode 100644 docs/breaktime/index.md

diff --git a/docs/breaktime/breaktime-api-spec.md b/docs/breaktime/breaktime-api-spec.md
new file mode 100644
index 0000000..2c1586c
--- /dev/null
+++ b/docs/breaktime/breaktime-api-spec.md
@@ -0,0 +1,227 @@
+# Breaktime API Specification
+This is the official API specification for the Breaktime back end. The back end is implemented as is described in the documentation below and should correspond exactly with how the back end behaves. If you find any inconsistencies please create a PR to amend the error.
+
+
+## Enums
+
+### Privilege Level
+
+The privilege level enum is all the possible privilege levels a user can have. This is stored in the users table as the privilege_level field. The possible options are:
+
+I don’t think we have these yet, leaving this here as a placeholder
+
+### Team Role
+
+The team role enum is all the possible states a use can be in in relation to a team. This is stored in the users_teams table on the backend as the team_role field. The possible options are:
+
+I don’t think we have these yet, leaving this here as a placeholder.
+
+## Auth Router
+
+This router is used to authenticate users. It handles logins, logouts, signups but also things like resetting passwords and secret keys. 
+
+### Login
+
+
+
+#### Request Body
+
+
+#### Responses
+
+##### `201 Created`
+
+
+##### `400 Bad Request`
+
+##### `401 Unauthorized`
+
+### Sign Up
+
+#### Request Body
+
+#### Responses
+
+##### `201 Created`
+ 
+##### `400 Bad Request`
+
+##### `409 Conflict`
+
+### Log Out
+
+
+#### Request Body
+
+
+#### Responses
+
+##### `204 No Content`
+
+### Refresh Access Token
+
+
+
+#### Request body
+
+
+#### Responses
+
+##### `201 Created`
+
+
+##### `401 Unauthorized`
+### Request Password Reset
+
+
+#### Request Body
+
+
+#### Responses
+
+##### `200 OK`
+
+
+##### `400 BAD REQUEST`
+
+
+## NoteSchema
+ 
+ Represents the database schema for a note. This can be one of the following types:
+  -- Comment: a general comment made for an entry or whole timesheet.
+  -- Report: a specific report to reflect an incident that happens and requires admin attention, e.g. no-show or late attendance
+
+#### Request body
+
+```json
+{
+  "Type": ENUM(["Comment", "Report"]),
+  "AuthorUUID": STRING.UUOD,
+  "DateTime": NUMBER,
+  "Content": STRING,
+  "State": ENUM(["Active", "Deleted"]),
+}
+```
+
+
+## ScheduleEntrySchema
+
+Represents the database schema for a schedule shift entry, made by a supervisor or admin
+
+#### Request body
+
+```json
+{
+  "StartDateTime": NUMBER,
+  "EndDateTime": NUMBER,
+}
+```
+
+
+## TimeEntrySchema
+
+Represents the database schema for a clockin/clockout pair in epoch
+
+#### Request body
+
+```json
+{
+  "StartDateTime": NUMBER,
+  "EndDateTime": NUMBER,
+}
+```
+
+
+## StatusSchema
+
+ Represents the database schema for the status of a timesheet. This could be one of the following types:
+  -- HoursSubmitted (Associate has submitted their hours worked)
+  -- HoursReviewed (Supervisor has reviewed and approved the associate-submitted hours)
+  -- ScheduleSubmitted (Supervisor has submitted the scheduled hours)
+  -- Finalized (Admin has approved the submitted hours and schedule, and resolved any issue necessary)
+ 
+  SubmittedDate reflects the time of last submission, whether from associate, supervisor, or admin.
+
+#### Request body
+
+```json
+{
+  "StatusType": ENUM([
+    "HoursSubmitted",
+    "HoursReviewed",
+    "ScheduleSubmitted",
+    "Finalized",
+  ]),
+  "SubmittedDateTime": NUMBER,
+    
+}
+```
+
+
+## TimesheetEntrySchema
+
+Represents the database schema for a single shift or entry in the weekly timesheet.
+
+#### Request body
+
+```json
+{
+  "AssociateTimes": TimeEntrySchema.optional(),
+  "SupervisorTimes": TimeEntrySchema.optional(),
+  "AdminTimes": TimeEntrySchema.optional(),
+  "Note": NoteSchema.optional(),
+    
+}
+```
+
+
+## Timesheet
+
+Represents the database schema for a weekly timesheet. A timesheet is defined as one week’s worth of timesheet entries, Sunday through Saturday. A unique timesheet is defined as a timesheet with a unique UserID and TimesheetID pair. There can be multiple timesheets per user.
+
+#### Request body
+
+```json
+{
+  "TimesheetID": NUMBER,
+  "UserID": STRING.UUID,
+  "StartDate": NUMBER,
+  "StatusList": ARRAY(StatusSchema),
+  "CompanyID": STRING,
+  "HoursData": ARRAY(TimesheetEntrySchema),
+  "ScheduleData": ARRAY(ScheduleEntrySchema),
+  "WeekNotes": ARRAY(NoteSchema),
+    
+}
+```
+
+
+## CompanySchema
+
+Represents the database schema for a company object, including list of users that belong to the company
+
+#### Request body
+
+```json
+{
+  "CompanyID": STRING,
+  "CompanyName": STRING,
+  "AssociateIDs": ARRAY(STRING.nonempty()),
+  "SupervisorIDs": ARRAY(STRING.nonempty()),  
+}
+```
+
+
+## UserCompaniesSchema
+
+Represents the database schema for a user company object, which contains the user ID and the company IDs they belong to
+
+#### Request body
+
+```json
+{
+  "UserID": STRING,
+  "AssociateCompanyIDs": ARRAY(STRING),
+  "SupervisorCompanyIDs": ARRAY(STRING), 
+}
+```
\ No newline at end of file
diff --git a/docs/breaktime/index.md b/docs/breaktime/index.md
new file mode 100644
index 0000000..a48a1a8
--- /dev/null
+++ b/docs/breaktime/index.md
@@ -0,0 +1,7 @@
+# Breaktime
+
+In this section you will find all the developer documentation related to our Breaktime project.
+
+## [API Specification](./breaktime-api-spec)
+
+The full API specification for our backend. This page lists every backend route and describes what it does, the request body and the possible responses. 
diff --git a/mkdocs.yml b/mkdocs.yml
index 7fae0af..4c74222 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -95,3 +95,6 @@ nav:
         - Home: jpal/index.md
     - LBFE:
         - Home: lbfe/index.md
+    - BREAKTIME:
+        - Home: breaktime/index.md
+        - API Specification: breaktime/breaktime-api-spec.md