Categories Scope

1. Break Down the Feature Lifecycle

1.1 Define the Feature Goals

• Purpose: Group and organize Articulate Rise 360 Microlearning modules under logical categories.

• Desired Outcomes:

  • Users (or admins) can easily find related modules grouped under a shared category (e.g., "Cybersecurity").

  • Categories are persistent entities in Firestore that reference modules by ID.

• Core User Interactions:

  • Admins: Create, update, and delete categories.

  • Admins: Add/remove module IDs to/from categories.

  • End users: View modules grouped by categories.

1.2 Establish Key Milestones

• Data Creation: Admins create categories (title, description, list of module IDs).

• Data Storage: Persist categories in Firestore, with generated _id.

• Data Retrieval: Fetch categories with their associated module IDs.

• Data Updates: Add/remove module IDs, update category metadata.

• Automation (future): Automatic category creation based on tags? (future consideration)

1.3 Prioritize MVP

• MVP Scope:

  • CRUD for categories (title, description, modules array).

  • Retrieve categories and their related modules.

• Future Enhancements:

  • Category ordering/priority.

  • Auto-population via tagging.

  • Bulk module assignment UI.

• Knowledge Gaps:

  • Confirm if categories should support nested/subcategories (ask stakeholders).

  • Confirm whether categories should store modules within or just reference them.

---

2. Identify Relevant Entities

2.1 List Entities

• Category:

  • _id (Firestore-generated)

  • title (string)

  • description (string, optional)

  • moduleIds (array of strings – references to Module _ids)

  • createdAt, updatedAt (timestamps)

• Module (existing entity):

  • _id (Firestore-generated)

  • title

  • contentUrl (Url linking directly to index.html in S3 Bucket)

  • categoryIds (optional reverse reference?)

2.2 Define Relationships

• One-to-Many:

  • A ModuleCategory can have many Module documents and/or Module IDs

• Many-to-Many (optional):

  • A Module could belong to multiple categories.

---

3. Plan API Routes

3.1 Define CRUD Operations (for ModuleCategory)

• POST /categories

  • Create a new category (title, description).

• GET /categories

  • List all categories.

• GET /categories/:categoryId

  • Retrieve a single category and its modules.

• PUT /categories/:categoryId

  • Update category details (title, description).

• DELETE /categories/:categoryId

  • Remove category and unlink modules.

3.2 Action-Specific Routes

• POST /categories/:categoryId/modules

  • Add module IDs to a category.

• DELETE /categories/:categoryId/modules/:moduleId

  • Remove a module from a category.

3.3 Validate Input/Output

• Validate that moduleIds being added exist in the modules collection.

• Ensure user permissions for each route (admin vs. user).

---

4. Feature Breakdown with Example Usage

4.1 Define User Scenarios

Scenario 1: Admin creates a category

1. Admin sends a POST /categories request with { title: "Cybersecurity", description: "Security awareness training modules" }.

2. Firestore generates _id, category stored with empty moduleIds.

Scenario 2: Admin adds modules to category

1. Admin calls PATCH /categories/:id with { moduleIds: ["abc123", "def456"] }.

2. Firestore updates moduleIds array in that category document.

Scenario 3: User views modules by category

1. User calls GET /categories.

2. Frontend displays list of categories with their module counts.

3. On click: GET /categories/:id returns category and associated module data.

4.2 Sample Firestore Document Model

collections:
  categories:
    categoryId:
      title: "Cybersecurity"
      description: "Security awareness training modules"
      moduleIds: ["abc123", "def456"]
      createdAt: <timestamp>
      updatedAt: <timestamp>