thoth-tech · JeffySam · Jan 30, 2026 · Jan 30, 2026 · Jan 30, 2026 · Jan 30, 2026
diff --git a/src/content/docs/Products/OnTrack/02-set-up-dev.mdx b/src/content/docs/Products/OnTrack/02-set-up-dev.mdx
@@ -462,12 +462,14 @@ The `*` symbol next to `development` confirms you are on the correct branch.
 ### Step 32: Exploring the Dashboard
 
 - After logging in, you’ll be directed to the dashboard showing **Enrolled Units**. Examples:
+
   - Introduction to Programming
   - Object-Oriented Programming
   - Artificial Intelligence for Games
   - Game Programming
 
 - Interact with the dashboard by:
+
   - Clicking on any enrolled unit to view details such as assignments and grades.
   - Using the "Select Unit" dropdown in the top-left corner to switch between units.
 

diff --git a/src/content/docs/Products/OnTrack/04-planner-board-etiquette.mdx b/src/content/docs/Products/OnTrack/04-planner-board-etiquette.mdx
@@ -17,13 +17,15 @@ efficient use of the planner board.
 <Steps>
 
 1. ### Claiming a Task
+
    - **Commit to work:** Only claim a task if you are ready to work on it.
    - **Unclaim if needed:** If you are unable to proceed with a task you've claimed, unclaim it so
      others can take over.
    - **Update status:** Once you claim a task, move it to the "Doing" column to signal that it's
      being actively worked on.
 
 2. ### Adding a Task
+
    - **Be clear and concise:** When adding a task, provide a meaningful title and a detailed
      description.
    - **Add checklists:** If the task involves multiple steps, include a checklist to outline them
@@ -32,6 +34,7 @@ efficient use of the planner board.
      `Tutorials` if it's tutorial based, or `usage examples` if it's a usage example.
 
 3. ### Moving Tasks
+
    - **Include relevant links:** When completing a task, attach links to the pull request (PR) and
      any other relevant information.
    - **Add a completion comment:** Leave a comment on the task card with the date you completed the
@@ -44,6 +47,7 @@ efficient use of the planner board.
    > detailed instructions.
 
 4. ### First Peer Review
+
    - **Follow the review process:** Adhere to the steps outlined in the
      [Peer Review Guide](/products/splashkit/06-peer-review).
    - **Request changes if needed:** Provide feedback and request changes if required.
@@ -53,6 +57,7 @@ efficient use of the planner board.
      task.
 
 5. ### Second Peer Review
+
    - **Follow similar steps:** Conduct the second peer review following the same guidelines as the
      first.
    - **Mentor Review:** After approving the PR, move it to the appropriate "Mentor Review" column.

diff --git a/src/content/docs/Products/OnTrack/05-planner-board-guidelines.mdx b/src/content/docs/Products/OnTrack/05-planner-board-guidelines.mdx
@@ -74,10 +74,12 @@ Agile principles to organize work into sprints.
 ### Sprint Workflow on Planner Boards
 
 1. **Before the Sprint**:
+
    - Plan tasks and create cards in the _To Do_ column.
    - Prioritize tasks based on team capacity and project goals.
 
 2. **During the Sprint**:
+
    - Move cards from _To Do_ → _In Progress_ → _Review_ as work progresses.
    - Communicate regularly during daily stand-ups to ensure alignment.
 
@@ -130,10 +132,12 @@ This is closely tied to task cards in the Planner Board.
 ### Steps for Upstream Reviews:
 
 1. **Connect PR to Planner Board**:
+
    - Link the PR to the corresponding task card for tracking.
    - Use comments in the card to summarize key changes in the PR.
 
 2. **Review Process**:
+
    - Conduct a thorough code review (refer to the Peer Review Guide).
    - Move the task card to _Review_ after the PR is created.
 

diff --git a/src/content/docs/Products/OnTrack/07-peer-review-web.mdx b/src/content/docs/Products/OnTrack/07-peer-review-web.mdx
@@ -76,26 +76,31 @@ contributions.
 ### Ontrack Peer-Review Prompts
 
 - **General Information**:
+
   - [ ] Type of Change: Clearly indicate the type of change (choose one):
     - [ ] Bug fix
     - [ ] New feature
     - [ ] Breaking change
     - [ ] Documentation update
 
 - **Code Quality**:
+
   - [ ] Repository: Ensure the PR is made to the correct repository.
   - [ ] Readability: Is the code easy to read and follow? Are comments included where necessary?
   - [ ] Maintainability: Can this code be maintained or extended easily in the future?
 
 - **Functionality**:
+
   - [ ] Correctness: Does the code meet the task requirements?
   - [ ] Existing Functionality: Has the impact on existing functionality been considered and tested?
 
 - **Testing**:
+
   - [ ] Test Coverage: Are unit tests provided for new or modified code?
   - [ ] Test Results: Have all tests passed successfully?
 
 - **Documentation**:
+
   - [ ] Documentation: Is the inline and external documentation updated and clear?
 
 - **Pull Request Details**:

diff --git a/...on/Deployment/Enhanced_Authentication/LDAP-and-devise-research-documentation.md b/...on/Deployment/Enhanced_Authentication/LDAP-and-devise-research-documentation.md
@@ -249,14 +249,11 @@ a broad overview will be sufficient for now.
 
 [3] heartcombo (n.d.) Devise [GitHub repository]. Available: <https://github.com/heartcombo/devise>
 
-[4] C. Schiewek (2020, Jul. 24). Devise LDAP Authenticatable [GitHub repository]. Available:
-<https://github.com/cschiewek/devise_ldap_authenticatable>
+[4] C. Schiewek (2020, Jul. 24). Devise LDAP Authenticatable [GitHub repository]. Available: <https://github.com/cschiewek/devise_ldap_authenticatable>
 
-[5] L. D. Hurley (n.d.). Devise Token Auth [GitHub repository]. Available:
-<https://github.com/lynndylanhurley/devise_token_auth>
+[5] L. D. Hurley (n.d.). Devise Token Auth [GitHub repository]. Available: <https://github.com/lynndylanhurley/devise_token_auth>
 
-[6] J. P. Riethmacher (n.d). Angular Token [GitHub repository]. Available:
-<https://github.com/neroniaky/angular-token>
+[6] J. P. Riethmacher (n.d). Angular Token [GitHub repository]. Available: <https://github.com/neroniaky/angular-token>
 
 ---
 

diff --git a/...t/Enhanced_Authentication/current-and-proposed-authentication-evaluation-5.1.md b/...t/Enhanced_Authentication/current-and-proposed-authentication-evaluation-5.1.md
@@ -12,8 +12,8 @@ title: Review of Current and Proposed Authentication Solutions
 [Proposed Authentication Enhancements](#proposed-authentication-enhancements)
 
 - [The Proposed Authentication Mechanism](#the-proposed-authentication-mechanism)
-- [Advancements of the Previous Authentication Mechanisms and how it Addresses Issues of the Old
-  Method]
+- [Advancements of the Previous Authentication Mechanisms and how it Addresses Issues of the
+  Old Method]
   (#advancements-of-the-previous-authentication-mechanisms-and-how-it-addresses-issues-of-the-old-method)
 - [Potential Issues and Concerns that must be Considered](#potential-issues-and-concerns-that-must-be-considered)
 

diff --git a/src/content/docs/Products/OnTrack/Documentation/Deployment/overview.md b/src/content/docs/Products/OnTrack/Documentation/Deployment/overview.md
@@ -50,9 +50,8 @@ deployment.
 
 Prior to deploying to GCP, we ran several tests locally (localhost) on our own workstations to
 determine the configuration changes required deploy Doubtfire successfully. On our individual
-workstations, we cloned the [Doubtfire-deploy-GCP repository]
-<https://github.com/thoth-tech/doubtfire-deploy-GCP> and modified the necessary files. We then used
-docker compose and Docker to run and deploy containers.
+workstations, we cloned the [Doubtfire-deploy-GCP repository] <https://github.com/thoth-tech/doubtfire-deploy-GCP>
+and modified the necessary files. We then used docker compose and Docker to run and deploy containers.
 
 ![doubtfire-localhost-compose](/doubtfire-localhost-compose.png "docker compose output")
 

diff --git a/...cs/Products/OnTrack/Documentation/Documentation/Proposed_Google_Auth_feature.md b/...cs/Products/OnTrack/Documentation/Documentation/Proposed_Google_Auth_feature.md
@@ -16,12 +16,14 @@ authentication system within a Ruby on Rails application.
 ### Previous Implementation Steps
 
 1. **Setup Using google-api-client:**
+
    - Integrated the gem to handle Google OAuth 2.0.
    - Created an endpoint in authentication_api.rb for Google authentication (/auth/google).
    - Configured token verification using Google::Apis::Oauth2V2::Oauth2Service.
    - Generated temporary tokens for authenticated users.
 
 2. **Challenges Identified:**
+
    - **Token Validation Failures:** Issues with API key configuration and scope validation caused
      intermittent failures.
    - **Complexity in Library Usage:** The google-api-client gem required extensive configuration and
@@ -122,6 +124,7 @@ token validation and user data retrieval.
 4. **Testing**
 
    Conduct functional and security testing for the updated implementation:
+
    - Validate token-based authentication using Google accounts.
    - Test various scenarios such as invalid tokens and token expiration.
    - Simulate edge cases like incorrect client credentials.

diff --git a/...Front End Migration/Deploy OnTrack/troubleshooting-docker-backup-for-ontrack.md b/...Front End Migration/Deploy OnTrack/troubleshooting-docker-backup-for-ontrack.md
@@ -31,6 +31,7 @@ What you guys need to do is
    > You need to change “docker compose” of file run-full.sh in doubtfire-deploy/development
 
 2. doubtfire-web doesn’t compile successfully:
+
    - Open terminal
    - Head to folder doubtfire-deploy/development by cd
    - Run this in 1 line:
@@ -41,6 +42,7 @@ What you guys need to do is
    ```
 
 3. doubtfire-api don’t run and exit with code 0/1.
+
    - Open terminal
    - Head to folder doubtfire-deploy/development by cd
    - Run this in 1 line:

diff --git a/...ts/OnTrack/Documentation/Front End Migration/Framework/angular-and-angularjs.md b/...ts/OnTrack/Documentation/Front End Migration/Framework/angular-and-angularjs.md
@@ -51,5 +51,5 @@ code reusability. So, The AngularJS framework provides reusable components for i
 
 Simplilearn.com. (2018). AngularJS Vs. Angular 2 Vs. Angular 4: Understanding the Differences.
 [online] Available at:
-<https://www.simplilearn.com/angularjs-vs-angular-2-vs-angular-4-differences-article> [Accessed 20
-Sep. 2022].
+<https://www.simplilearn.com/angularjs-vs-angular-2-vs-angular-4-differences-article> [Accessed
+20 Sep. 2022].
diff --git a/...ntation/Front End Migration/Migration/PROJECTS_INDEX_MIGRATION_INVESTIGATION.md b/...ntation/Front End Migration/Migration/PROJECTS_INDEX_MIGRATION_INVESTIGATION.md
@@ -0,0 +1,109 @@
+---
+title: Projects Index Migration Investigation
+description: Investigation of the projects/index parent state migration from AngularJS to Angular
+---
+
+# Projects Index Migration Investigation
+
+Date: January 27, 2026\
+Author: Jeffy Sam\
+Area: Projects module – index (parent) state
+
+## Purpose
+
+This document investigates the current state of the projects/index parent state migration from
+AngularJS to Angular. The goal is to confirm what has already been migrated, identify what remains
+incomplete, and assess whether the state is safe to finalise without breaking dependent child
+states.
+
+## Current State of the Migration
+
+The Angular implementation of the projects/index parent state already exists and is functionally
+complete. The following Angular files are present and active:
+
+- index.component.ts
+- index.component.html
+- index.component.scss
+- index.state.ts
+- index.module.ts
+
+The Angular parent state handles route parameter extraction, project loading, unit resolution, user
+role resolution, global view state configuration, and explicit lifecycle cleanup. No runtime or
+console errors are observed when the Angular implementation is active.
+
+The legacy AngularJS implementation still exists in the repository and includes the following files:
+
+- index.coffee
+- index.tpl.html (if present)
+
+As long as these legacy files remain, both AngularJS and Angular implementations may coexist.
+
+## Responsibilities of the Parent State
+
+The projects/index parent state provides shared context for all project-related child states. Its
+responsibilities include:
+
+- Loading the project using the route projectId
+- Resolving the associated unit
+- Resolving the current user's role
+- Setting the global application view context to PROJECT
+- Exposing project, unit, and unitRole to child states
+
+These responsibilities are fully implemented in the Angular version and mirror the legacy behaviour.
+
+## AngularJS vs Angular Behaviour
+
+The Angular implementation preserves all functional behaviour while introducing:
+
+- Explicit lifecycle management
+- Explicit subscription cleanup
+- Strong typing via TypeScript
+- Observable-based route parameter handling
+- Reduced reliance on implicit scope inheritance
+
+No functional differences have been identified.
+
+## Dependent Child States
+
+The following child states depend on the projects/index parent state for shared context:
+
+- projects/dashboard
+- projects/tutorials
+- projects/portfolio
+- projects/groups
+- projects/outcomes
+
+Any issues in the parent state will directly affect these routes.
+
+## Verification Required Before Cleanup
+
+Before legacy files can be safely removed, the following must be verified:
+
+- Project loading works for valid and invalid project IDs
+- Unit and user role resolve correctly
+- Global view state is set to PROJECT
+- Navigation to all child states works correctly
+- Page refresh and deep linking behave correctly
+- No routing or console errors occur
+- No memory leaks from subscriptions
+
+## Files in Scope
+
+Angular files currently in use:
+
+- index.component.ts
+- index.component.html
+- index.component.scss
+- index.state.ts
+- index.module.ts
+
+Legacy files pending removal:
+
+- index.coffee
+- index.tpl.html
+
+## Conclusion
+
+The Angular implementation of the projects/index parent state is functionally complete. The
+migration is currently pending verification and cleanup. Once verified, the legacy AngularJS files
+can be removed and the parent state can be considered fully migrated.