docs: migrate confluence documentation to repo

README.md

@@ -19,9 +19,9 @@ This project was initally associated with The University of Auckland SOFTENG 761
 
 # Contributing
 
-Onboarding documentation can be found in the Github Wiki under `Wiki/Onboarding`.
+[Documentation](./wiki/VPS%20Home.md) for the project lives here in this repo, with some basic onboarding / setup information and (very!) partial documentation of the codebase.
 
-This project uses the [conventional commits](https://www.conventionalcommits.org) specification for commit messages.
+Try to use the [conventional commits](https://www.conventionalcommits.org) specification for commit messages, it makes it easier for everyone.
 
 # Contributors ✨
 

wiki/Auth Implementation Guide.md

@@ -0,0 +1,117 @@
+# Auth Implementation Guide
+
+## Frontend Auth
+
+Accessing Auth Protected API Endpoints
+
+To access an authentication-protected backend, follow these steps:
+
+### 1. Include the Auth Token in the Header
+
+Ensure that the authorization token is included in the header of every request. This token is typically retrieved after a successful login.
+
+Example:
+
+```
+// import user Token from Context
+const { user, loading, error } = useContext(AuthenticationContext);
+
+//Check if finished loading
+if (loading) {
+  // handle loading state
+  //show loading spinner or smt
+} if (error) {
+  //handle error
+} if (user) {
+  const token = await user.getIdToken(); // Function to retrieve the auth token
+  const response = await fetch("https://your-api-endpoint.com", {
+    method: "GET",
+    headers: {
+      Authorization: `Bearer ${token}`,
+      "Content-Type": "application/json",
+    },
+  });
+  const data = await response.json();
+}
+```
+
+### 2. Handle Token Expiry and Refresh
+
+Ensure your application handles token expiry. Implement logic to refresh the token when it expires.
+
+Example:
+
+```
+const fetchWithAuth = async (url, options = {}) => {
+  let token = await getAuthToken();
+  let response = await fetch(url, {
+    ...options,
+    headers: {
+      ...options.headers,
+      Authorization: `Bearer ${token}`,
+      "Content-Type": "application/json",
+    },
+  });
+  if (response.status === 401) {
+    // Refresh the token if it's expired and retry the request
+    token = await refreshAuthToken();
+    response = await fetch(url, {
+      ...options,
+      headers: {
+        ...options.headers,
+        Authorization: `Bearer ${token}`,
+        "Content-Type": "application/json",
+      },
+    });
+  }
+  return response;
+};
+```
+
+## Backend Auth
+
+### Implementing an Auth Protected Backend Endpoint
+
+To implement authentication-protected backend endpoints using Firebase authentication and scenario-based authorization, follow these steps:
+
+#### Protect Your API Routes with the Middlewares
+
+Apply these the Firebase authorization and scenario authentication middlewares to your API routes to ensure they are protected by both Firebase authorization and scenario-based authentication .
+
+Example:
+
+(Example is from `scenario.js`)
+
+1. Import authorization from firebaseAuth and import Scenario Authentication from scenarioAuth (also make sure you import the functions from the dao) 
+
+```
+import { Router } from "express";
+import auth from "../../middleware/firebaseAuth";
+import scenarioAuth from "../../middleware/scenarioAuth";
+import {
+  createScenario,
+  retrieveScenarioList,
+  updateScenario,
+  deleteScenario,
+  updateDurations,
+} from "../../db/daos/scenarioDao";
+import { retrieveAssignedScenarioList } from "../../db/daos/userDao";
+```
+
+2. Apply Firebase Authorization protection to your routes
+
+```
+// Apply Firebase auth middleware to all routes
+router.use(auth);
+
+// put API end points that require firebase Auth here
+```
+
+3. Apply scenario Authentication protection to your routes
+
+```
+// Apply scenario auth middleware
+router.use("/:scenarioId", scenarioAuth);
+
+// put API end points that require scenario auth here
+```

wiki/backend-api.md → wiki/Backend API.md

@@ -1,4 +1,7 @@
-## Backend API
+# Backend API
+
+> [!WARNING]
+> I'm unsure how accurate this documentation is, given that it wasn’t updated at all during 2024. If you find something inaccurate or something missing, please correct it or add in some brief documentation for the endpoint. If you’re unsure ask someone else, it would be great to get it fully accurate at some point. - Hartej
 
 ### Routes
 

wiki/Editor/Text Model.md

@@ -0,0 +1,69 @@
+# Text Model
+
+The text model is going to be a tree structure to support span based styling, similar to other editors like google slides.
+
+> [!WARNING]
+> Use the types defined in the codebase as the actual source of truth, since this document might not reflect any minor changes made in the actual implementation 
+
+## Text Structure
+
+### Text Shape
+
+The highest level text structure, used for standard text boxes and other components like buttons.
+
+```ts
+interface TextShape {
+	id: string;
+	type: "text";
+	x: number;
+	y: number;
+	width: number;
+	height: number;
+	blocks: TextBlock[];
+	style?: Partial<BaseTextStyle>;
+}
+```
+
+### Text Block
+
+Represents paragraph blocks.
+
+```ts
+interface TextBlock {
+	id: string;
+	style?: Partial<BlockTextStyle>;
+	spans: TextSpan[];
+}
+```
+
+### Text Span
+
+```ts
+interface TextSpan {
+	text: string;
+	style?: Partial<SpanTextStyle>;
+}
+```
+
+## Style Structure
+
+The lower level properties (block and span) take precedence over the base properties when both are defined.
+
+```ts
+interface BaseTextStyle extends BlockTextStyle, SpanTextStyle {}
+
+interface BlockTextStyle {
+	alignment: "left" | "centre" | "right";
+	lineHeight: number;
+}
+
+interface SpanTextStyle {
+	fontFamily: "string";
+	fontSize: number;
+	fontWeight: string;
+	fontStyle: string;
+	textDecoration: string;
+	textColor: HexString;
+	highlightColor: HexString;
+}
+```

wiki/Onboarding/Git Conventions.md

@@ -0,0 +1,23 @@
+# Git Conventions
+
+## Branches
+
+Create a branch for your issue and name the branch `VPS-[issue no.]/[issue name]` (if the issue name is long, a shorter version is also fine)
+
+- e.g. `VPS-007/add_labels_in_toolbar`
+
+### Merging
+
+When working on branches, we want to favor **rebasing** over creating merge commits. Rebasing maintains a cleaner, linear commit history, making it easier to review changes and understand the progression of the codebase. Its also helpful to rebase often when new commits are being pushed to main, so that any conflicts are smaller and easier to resolve.
+
+## Commit Messages
+
+The project follows the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification for commit messages and descriptions, which is a loose specification that allows for rapid development while making sure commits are thought out and purposeful.
+
+## Pull requests
+
+Once you've made all your commits, open a PR with the same name as the branch `(VPS-[issue no.]/[issue name])` and fill in the details of the template. If you want to look at it the PR template can be found [here](https://github.com/UoaWDCC/VPS/blob/).
+
+After the PR passes the validation pipeline (format and linting) and passes the required no. of approvals (should be 2), you can merge the PR preferably using either **squash and merge** or **rebase and merge** so that the commit history stays clean and unpolluted by merge commits.
+
+Make sure you delete the branch after you merge the PR, it’s not a good idea to re-use branches after their changes have been merged as it could easily lead to conflicts if you’re not careful. We also don’t want stale branches lying around.