Re_Figma_Code/DetailedReports_Analysis.md

Detailed Reports Page - Data Availability Analysis

Overview

This document analyzes what data is currently available in the backend and what information is missing for implementing the DetailedReports page.

---

1. Request Lifecycle Report

✅ Available Data:

• Request Basic Info:

  • requestNumber (RE-REQ-2024-XXX)
  • title
  • priority (STANDARD/EXPRESS)
  • status (DRAFT, PENDING, IN_PROGRESS, APPROVED, REJECTED, CLOSED)
  • initiatorId → Can get initiator name via User model
  • submissionDate
  • closureDate
  • createdAt

• Current Stage Info:

  • currentLevel (1-N)
  • totalLevels
  • Can get current approver from approval_levels table

• TAT Information:

  • totalTatHours (cumulative TAT)
  • Can calculate overall TAT from submissionDate to closureDate or updatedAt
  • Can get level-wise TAT from approval_levels.tat_hours
  • Can get TAT compliance from tat_alerts table

• From Existing Services:

  • getCriticalRequests() - Returns requests with breach info
  • getUpcomingDeadlines() - Returns active level info
  • getRecentActivity() - Returns activity feed

❌ Missing Data:

1. Current Stage Name/Description:

   • Need to join with approval_levels to get level_name for current level
   • Currently only have currentLevel number

2. Overall TAT Calculation:

   • Need API endpoint that calculates total time from submission to current/closure
   • Currently have totalTatHours but need actual elapsed time

3. TAT Compliance Status:

   • Need to determine if "On Time" or "Delayed" based on TAT vs actual time
   • Can calculate from tat_alerts.is_breached but need endpoint

4. Timeline/History:

   • Need endpoint to get all approval levels with their start/end times
   • Need to show progression through levels

🔧 What Needs to be Built:

• New API Endpoint: /dashboard/reports/lifecycle
  • Returns requests with:
    • Full lifecycle timeline (all levels with dates)
    • Overall TAT calculation
    • TAT compliance status (On Time/Delayed)
    • Current stage name
    • All approvers in sequence

---

2. User Activity Log Report

✅ Available Data:

• Activity Model Fields:

  • activityId
  • requestId
  • userId → Can get user name from User model
  • userName (stored directly)
  • activityType (created, assignment, approval, rejection, etc.)
  • activityDescription (details of action)
  • ipAddress (available in model, but may not be logged)
  • createdAt (timestamp)
  • metadata (JSONB - can store additional info)

• From Existing Services:

  • getRecentActivity() - Already returns activity feed with pagination
  • Returns: activityId, requestId, requestNumber, requestTitle, type, action, details, userId, userName, timestamp, priority

❌ Missing Data:

1. IP Address:

   • Field exists in model but may not be populated
   • Need to ensure IP is captured when logging activities

2. User Agent/Device Info:

   • Field exists (userAgent) but may not be populated
   • Need to capture browser/device info

3. Login Activities:

   • Current activity model is request-focused
   • Need separate user session/login tracking
   • Can check users.last_login but need detailed login history

4. Action Categorization:

   • Need to map activityType to display labels:
     • "created" → "Created Request"
     • "approval" → "Approved Request"
     • "rejection" → "Rejected Request"
     • "comment" → "Added Comment"
     • etc.

5. Request ID Display:

   • Need to show request number when available
   • Currently getRecentActivity() returns requestNumber ✅

🔧 What Needs to be Built:

• Enhance Activity Logging:

  • Capture IP address in activity service
  • Capture user agent in activity service
  • Add login activity tracking (separate from request activities)

• New/Enhanced API Endpoint: /dashboard/reports/activity-log

  • Filter by date range
  • Filter by user
  • Filter by action type
  • Include IP address and user agent
  • Better categorization of actions

---

3. Workflow Aging Report

✅ Available Data:

• Request Basic Info:

  • requestNumber
  • title
  • initiatorId → Can get initiator name
  • priority
  • status
  • createdAt (can calculate days open)
  • submissionDate

• Current Stage Info:

  • currentLevel
  • totalLevels
  • Can get current approver from approval_levels

• From Existing Services:

  • getUpcomingDeadlines() - Returns active requests with TAT info
  • Can filter by days open using createdAt or submissionDate

❌ Missing Data:

1. Days Open Calculation:

   • Need to calculate from submissionDate (not createdAt)
   • Need to exclude weekends/holidays for accurate business days

2. Start Date:

   • Should use submissionDate (when request was submitted, not created)
   • Currently have this field ✅

3. Assigned To:

   • Need current approver from approval_levels where level_number = current_level
   • Can get from approval_levels.approver_name ✅

4. Current Stage Name:

   • Need approval_levels.level_name for current level
   • Currently only have level number

5. Aging Threshold Filtering:

   • Need to filter requests where days open > threshold
   • Need to calculate business days (excluding weekends/holidays)

🔧 What Needs to be Built:

• New API Endpoint: /dashboard/reports/workflow-aging
  • Parameters:
    • threshold (days)
    • dateRange (optional)
    • page, limit (pagination)
  • Returns:
    • Requests with days open > threshold
    • Business days calculation
    • Current stage name
    • Current approver
    • Days open (business days)

---

Summary

✅ Can Show Immediately:

1. Request Lifecycle Report (Partial):

   • Request ID, Title, Priority, Status
   • Initiator name
   • Submission date
   • Current level number
   • Basic TAT info

2. User Activity Log (Partial):

   • Timestamp, User, Action, Details
   • Request ID (when applicable)
   • Using existing getRecentActivity() service

3. Workflow Aging (Partial):

   • Request ID, Title, Initiator
   • Days open (calendar days)
   • Priority, Status
   • Current approver (with join)

❌ Missing/Incomplete:

1. Request Lifecycle:

   • Full timeline/history of all levels
   • Current stage name (not just number)
   • Overall TAT calculation
   • TAT compliance status (On Time/Delayed)

2. User Activity Log:

   • IP Address (field exists but may not be populated)
   • User Agent (field exists but may not be populated)
   • Login activities (separate tracking needed)
   • Better action categorization

3. Workflow Aging:

   • Business days calculation (excluding weekends/holidays)
   • Current stage name
   • Proper threshold filtering

🔧 Required Backend Work:

1. New Endpoints:

   • /dashboard/reports/lifecycle - Full lifecycle with timeline
   • /dashboard/reports/activity-log - Enhanced activity log with filters
   • /dashboard/reports/workflow-aging - Aging report with business days

2. Enhancements:

   • Capture IP address in activity logging
   • Capture user agent in activity logging
   • Add login activity tracking
   • Add business days calculation utility
   • Add level name to approval levels response

3. Data Joins:

   • Join approval_levels to get current stage name
   • Join users to get approver names
   • Join tat_alerts to get breach/compliance info

---

Recommendations

Phase 1 (Quick Win - Use Existing Data):

• Implement basic reports using existing services
• Show available data (request info, basic activity, calendar days)
• Add placeholders for missing data

Phase 2 (Backend Development):

• Build new report endpoints
• Enhance activity logging to capture IP/user agent
• Add business days calculation
• Add level name to responses

Phase 3 (Full Implementation):

• Complete all three reports with full data
• Add filtering, sorting, export functionality
• Add date range filters
• Add user/role-based filtering