docs: add Units module migration investigation and plan

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.
 

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.

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.
 

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**:

src/content/docs/Products/OnTrack/Documentation/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>
 
 ---
 

src/content/docs/Products/OnTrack/Documentation/Deployment/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)
 

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")
 

src/content/docs/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.

src/content/docs/Products/OnTrack/Documentation/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:

src/content/docs/Products/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].

src/content/docs/Products/OnTrack/Documentation/Front End Migration/Migration/UNITS_MODULE_MIGRATION_INVESTIGATION.md

@@ -0,0 +1,163 @@
+---
+title: Units Module Migration Investigation
+description:
+  Investigation summary of the current migration state of the Units module from AngularJS
+  (CoffeeScript) to Angular (TypeScript).
+---
+
+# Units Module Migration Investigation
+
+**Date:** January 28, 2026  
+**Author:** Jeffy Sam  
+**Scope:** Units module foundations (state aggregation and parent states)
+
+---
+
+## Purpose
+
+This document records the current state of the Units module migration from AngularJS to Angular.  
+Its goal is to clearly identify what has already been migrated, what remains in AngularJS, and which
+areas act as blockers for downstream work.
+
+This is an **investigation document**, not an implementation plan.
+
+---
+
+## High-Level Structure of the Units Module
+
+The Units module follows a layered UI-Router hierarchy:
+
+units (states aggregator) └─ units/index (abstract parent) ├─ units/tasks (intermediate parent) │ ├─
+inbox │ ├─ definition │ └─ viewer ├─ admin (edit) ├─ groups ├─ students/\* ├─ analytics └─ rollover
+
+This hierarchy makes parent states critical dependencies for all child migrations.
+
+---
+
+## Current Migration Status
+
+### ✅ What is already in Angular
+
+#### 1) Units states aggregator
+
+- `src/app/units/states/states.ts` exists and acts as the Units states aggregator.
+- It imports Units sub-state modules and registers their UI-Router configuration.
+- This replaces the legacy `states.coffee` file.
+
+#### 2) `units/index` Angular implementation exists
+
+Angular files exist for the abstract parent state:
+
+- `index.component.ts`
+- `index.component.html`
+- `index.component.scss`
+- `index.state.ts`
+- `index.module.ts`
+
+The work is currently tracked in **PR #435**.
+
+⚠️ The legacy AngularJS files still exist and are active:
+
+- `src/app/units/states/index/index.coffee`
+- `src/app/units/states/index/index.tpl.html`
+
+These must be removed once the Angular parent is finalised.
+
+---
+
+### ⚠️ What is still AngularJS (blocking work)
+
+The following states remain implemented using AngularJS (CoffeeScript):
+
+- `units/states/tasks/tasks.coffee` _(intermediate parent)_
+- `units/states/tasks/inbox/inbox.coffee`
+- `units/states/tasks/definition/definition.coffee`
+- `units/states/tasks/viewer/viewer.coffee`
+- `units/states/edit/edit.coffee`
+- `units/states/groups/groups.coffee`
+- `units/states/students-list/students-list.coffee`
+- `units/states/portfolios/portfolios.coffee`
+- `units/states/analytics/analytics.coffee`
+- `units/states/rollover/rollover.coffee`
+
+---
+
+## Key Findings
+
+### 1) `units/index` is close, but not final
+
+Although an Angular implementation exists, the presence of legacy AngularJS files means both systems
+can still be active. Until the legacy files are removed, child migrations remain risky.
+
+### 2) `units/tasks` is the primary blocker
+
+`units/tasks` is an intermediate parent state that provides shared task context to multiple
+children.  
+It cannot be skipped or treated as a leaf migration.
+
+### 3) Scope inheritance is still relied upon
+
+Child states expect data from parent states via AngularJS `$scope`, including:
+
+- `unit`
+- `unitRole`
+- `taskData`
+
+This dependency must be replaced before child migrations can be completed cleanly.
+
+### 4) Placeholder Angular modules can be misleading
+
+Several Angular `.module.ts` files exist but only provide scaffolding.  
+They do **not** indicate that the corresponding state has been migrated.
+
+---
+
+## Parent Responsibilities (Current)
+
+### `units/index`
+
+Provides:
+
+- `unit`
+- `unitRole`
+- global Units view context
+
+### `units/tasks`
+
+Provides:
+
+- `taskData` (task selection and state)
+- query-parameter synchronisation (`taskKey`)
+- shared task lifecycle logic
+
+---
+
+## Files Identified for Removal (when ready)
+
+### After `units/index` is finalised
+
+- `src/app/units/states/index/index.coffee`
+- `src/app/units/states/index/index.tpl.html`
+
+### After `units/tasks` is migrated
+
+- `src/app/units/states/tasks/tasks.coffee`
+
+Additional child-level removals should occur only after their respective migrations are complete.
+
+---
+
+## Conclusion
+
+The Units module migration is **partially complete** at the foundation level.  
+Progress is currently gated by two parent states:
+
+1. Finalising `units/index`
+2. Migrating `units/tasks`
+
+Once these are resolved, child migrations can proceed safely without AngularJS scope inheritance.
+
+---
+
+**Status:** Investigation complete  
+**Next step:** Finalise parent states before addressing leaf states