Manage project RAG statuses

Task: Manage RAG Status Settings in Admin

Description

Add admin management functionality for RAG statuses, allowing administrators to create, edit, deactivate, and configure CSS classes for each status. This replaces hardcoded RAG status values with a configurable lookup table, similar to the existing Phases management.

Background

Currently, RAG statuses (Green, Amber-Green, Amber, Amber-Red, Red) are hardcoded throughout the application. This makes it difficult to:

• Add or modify RAG statuses
• Customize badge styling per status
• Deactivate statuses without code changes
• Maintain consistency across the application

Requirements

Admin Interface

• Create admin page at /Admin/RagStatuses (following the Phases management pattern)
• Allow admins to:
  • View all RAG statuses in a table (sorted by SortOrder, then Name)
  • Create new RAG statuses with:
    • Name (required, max 100 chars)
    • Description (optional)
    • Sort Order (for display ordering)
    • CSS Class (for badge styling, e.g., "badge badge-green")
    • Active/Inactive status
  • Edit existing RAG statuses
  • Delete RAG statuses (with validation to prevent deletion if in use by projects)
  • Set statuses as Active/Inactive

Data Model

• Create RagStatusLookup model with:
  • Id, Name, Description, SortOrder, IsActive, CssClass, CreatedAt, UpdatedAt
• Add RagStatusLookups DbSet to CompassDbContext
• Update Project model to use RagStatusLookupId foreign key
• Update ProjectRagHistory model to use RagStatusLookupId foreign key
• Maintain backward compatibility with existing RagStatus string property (marked as obsolete)

Application Updates

• Update UpdateRagStatus action to use lookup IDs instead of strings
• Update _RagTracking.cshtml view to:
  • Load RAG statuses from lookup table
  • Use CSS classes from lookup for badge styling
  • Fall back to legacy string-based logic for backward compatibility
• Update Details action to include RagStatusLookup in queries and load active statuses
• Add CSS classes to service-manual.css for default RAG status badges

Acceptance Criteria

• Admin can access RAG statuses management page at /Admin/RagStatuses
• Admin can create new RAG statuses with all required fields
• Admin can edit existing RAG statuses
• Admin can set RAG statuses as Active/Inactive
• Admin cannot delete RAG statuses that are in use by projects
• RAG statuses are displayed in sort order (SortOrder, then Name)
• CSS classes can be set per RAG status for badge styling
• Project RAG status updates use the lookup table
• RAG status badges use CSS classes from the lookup table
• Backward compatibility is maintained for existing RagStatus string values
• All existing RAG status functionality continues to work

Technical Implementation Notes

• Follow the existing Phases management pattern (AdminController.Phases() actions and Views/Admin/Settings/Phases.cshtml)
• Use Entity Framework migrations to add the RagStatusLookups table
• Seed initial RAG statuses (Green, Amber-Green, Amber, Amber-Red, Red) with appropriate CSS classes
• CSS classes should be added to service-manual/wwwroot/css/service-manual.css
• The RagStatus string property should be marked with [Obsolete] attribute but kept for backward compatibility

Related Work

• Epic: Administration functions
• Feature: Application wide settings
• Related: Phase management (similar pattern)

Dependencies

• Database migration required
• Initial data seeding required for existing RAG statuses

Testing Checklist

• Test creating new RAG status
• Test editing existing RAG status
• Test deleting unused RAG status
• Test attempting to delete RAG status in use (should fail with error message)
• Test setting RAG status as inactive (should not appear in dropdowns)
• Test updating project RAG status using new lookup
• Test RAG status badges display with correct CSS classes
• Test backward compatibility with existing projects using string RagStatus

Start by reading the existing AdminController.Phases() actions and Views/Admin/Settings/Phases.cshtml to understand the management pattern. Then trace UpdateRagStatus, Details, _RagTracking.cshtml, CompassDbContext, and service-manual/wwwroot/css/service-manual.css. Done means the lookup-backed admin workflow, migration and seed data, project updates, styling, and backward compatibility satisfy the acceptance criteria.