[FEAT]: Implement incident analytics and automatic graphical reports

[marcvergees]

📝 Description

A clear and concise description of what the feature is.

Implement incident analytics and automatic graphical reports for reported incidents. When the "Analytics / Report Graphics" tab is opened, the system should automatically generate visualizations (bar charts, pie/donut charts, time-series, heatmaps, and top-N lists) that surface common attributes across reported incidents (type, severity, status, reporter, assignee, environment, tags, affected component, etc.). Analytics must be derived from existing incident data; do not create new database tables.

💡 Rationale

Why is this needed?

Operators and incident managers need quick, actionable insights into incident trends and commonalities without manually exporting data or running ad-hoc queries. An automated analytics view speeds triage, helps prioritize fixes, and surfaces systemic issues (hot components, recurring error messages, high-severity clusters) visually.

🛠️ Proposed Solution

A brief sketch of how we might implement this.

• Frontend

  • Add/extend the Analytics / Report Graphics tab UI to render charts when the tab is opened.
  • Use an existing or repo-consistent charting library (Chart.js, ECharts, Recharts, or ApexCharts) and build reusable chart components.
  • Provide filters: date range, project, incident type, severity, tags, assignee, environment.
  • Support drill-down by clicking chart segments to view underlying incident lists.
  • Add export options: PNG/SVG for charts and CSV for aggregated data.

• Backend

  • Add aggregation endpoints (e.g. GET /api/analytics/incidents?metrics=...) that compute aggregates on-demand using existing incident schema (SQL GROUP BY). Do NOT create new DB tables.
  • Prefer server-side SQL aggregations for large datasets; fall back to in-memory aggregation for small datasets or prototyping.
  • Add short-lived caching (in-memory or Redis) with a configurable TTL for common queries to improve repeated load performance.
  • Implement paging/limits for drill-down lists and top-N queries (e.g., top 50), and provide full CSV export for complete results.

• Performance & Safety

  • Use proper indexing for aggregation columns to keep queries efficient. For very large datasets, consider optional background pre-aggregation or materialized views as a follow-up (out of initial scope as it requires DB changes).
  • Mask or exclude PII from default aggregates/exports unless explicitly authorized.

• Tests & Docs

  • Add unit/integration tests for aggregation endpoints and UI rendering paths.
  • Document endpoints, front-end components, and how to add new analytics metrics in the repository docs.

• Example checklist

  • Logic change in src/
  • Update to dependency list if a charting library is added
  • API aggregation endpoints implemented and tested
  • Frontend Analytics tab renders charts automatically on open
  • Export and drill-down implemented

✅ Acceptance Criteria

How will we know this is finished?

• When the Analytics / Report Graphics tab is opened, charts are automatically generated (no manual trigger required).
• Bar charts and pie/donut charts exist for the listed metrics (type, status, severity, assignee, component, environment).
• Time-series visualization shows incidents over time and respects date-range filters.
• Drill-down from charts to underlying incident list works and is paginated.
• No new DB tables are created; analytics are derived from existing incident data.
• Charts can be exported as images and aggregated results exported as CSV.
• Reasonable performance for medium-sized datasets; caching implemented for repeated queries.
• Documentation added explaining endpoints, caching, and how to extend metrics.

📌 Additional Context

• Keep implementation consistent with existing repository patterns (preferred charting library, API conventions, auth). If the repo already uses a charting library, prefer that to avoid adding dependencies.
• This feature focuses on on-demand aggregation (no scheduled reporting) and explicitly avoids new DB schema changes.
• Suggested visualizations: bar charts, pie/donut charts, line/area time-series, heatmaps/matrices, and top-N lists.