[DOCS] Analisi Modulo C — Calendario unico scadenze (aggregatore read-only) + stima aggiornata A+B+C
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
DevEnv nis2-agile
co-authored by
Claude Opus 4.8
Claude Opus 4.8
parent
d6f445121e
commit
18a4a0b509
@@ -94,3 +94,61 @@ Ogni fase è committata+pushata e LIVE in autonomia (1 sola istanza L1). Prossim
|
||||
|
||||
## Esito atteso
|
||||
Con questi due moduli l'auditor ISO troverebbe in-app: SoA, rischi, NC/CAPA, formazione, asset, evidenze, **programma+report audit interni** e **verbale del riesame** — cioè **tutte le registrazioni gestionali delle clausole 4–10**. Resterebbe solo da dimostrare i controlli tecnici A.7/A.8 sull'infrastruttura reale (non delegabili ad alcun software).
|
||||
|
||||
---
|
||||
|
||||
# MODULO C — Calendario unico delle scadenze (richiesta utente 2026-06-17)
|
||||
|
||||
## Obiettivo
|
||||
Una **vista calendario unica** che raccoglie **ogni scadenza** del sistema in un solo posto (griglia mensile + lista + filtri), con stato (in ritardo / in scadenza / futura) e link diretto all'elemento. Oggi le scadenze sono sparse in molti moduli e aggregate solo in parte (dashboard "prossime scadenze" a 30 gg + Scadenziario revisioni periodiche): manca la vista d'insieme completa.
|
||||
|
||||
## Analisi — sorgenti di scadenza già presenti (verificate nel codice/DB)
|
||||
| Sorgente | Campo data | Modulo |
|
||||
|---|---|---|
|
||||
| Incidenti Art.23 | `early_warning_due` / `notification_due` / `final_report_due` (calcolati) | incidents |
|
||||
| Revisione policy/procedure | `policies.next_review_date` | Policy |
|
||||
| Trattamenti rischio | `risk_treatments.due_date` | Rischi |
|
||||
| Revisione controlli | `compliance_controls.next_review_date` | Audit/Controlli |
|
||||
| Non conformità / azioni | `non_conformities.target_close_date`, `capa_actions.due_date` | NCR/CAPA |
|
||||
| Formazione | `training_assignments.due_date` | Formazione |
|
||||
| Attività stakeholder | `stk_activities.due_date` / `planned_date` | Stakeholder (C5) |
|
||||
| Scadenziario revisioni | `review_schedule.next_review_date` (ricorrenti) | Scadenziario (A4 4.4) |
|
||||
| **Audit interni** (nuovo) | `internal_audits.planned_date` | Modulo A |
|
||||
| **Decisioni riesame** (nuovo) | `management_review_decisions.due_date` | Modulo B |
|
||||
|
||||
Esistente da riusare: `DashboardController::deadlines` (union incidenti/policy/trattamenti/formazione a 30 gg) — ne generalizzo il pattern. `review_schedule` resta per le revisioni **ricorrenti** (ha `frequency_months`); il calendario lo **include** come una delle sorgenti.
|
||||
|
||||
## Decisione architetturale — aggregatore READ-ONLY (nessuna tabella nuova)
|
||||
Le scadenze **vivono già** nei moduli sorgente, ciascuna col proprio ciclo di vita: duplicarle in una tabella calendario creerebbe disallineamenti. Quindi: **endpoint aggregatore in sola lettura** che fa UNION live di tutte le sorgenti e normalizza gli eventi. **Niente migrazione** per il calendario (mig. solo per A/B). Vantaggi: sempre coerente, additivo, zero rischio dato.
|
||||
|
||||
### Endpoint — `CalendarController` (slug `calendar`)
|
||||
- `GET /api/calendar/events?from=YYYY-MM-DD&to=YYYY-MM-DD&types=...` → lista eventi normalizzati:
|
||||
`{ source, type, title, date, status (overdue|due_soon|upcoming|done), severity, entity_type, entity_id, link }`.
|
||||
org-scoped, anti-IDOR (filtro `organization_id` su ogni sorgente), stato calcolato live (come `review_schedule`).
|
||||
- `GET /api/calendar/summary` → conteggi per stato/tipo (per badge dashboard).
|
||||
- Riusa/centralizza la logica di `DashboardController::deadlines` (che può poi delegare a questo).
|
||||
- Sola lettura → `requireOrgAccess()`.
|
||||
|
||||
### Frontend — `calendario.html`
|
||||
- **Griglia mensile** (HTML/CSS puro, dependency-free) con pallini colorati per tipo + navigazione mese prec./succ.; **vista lista** alternativa (ordinata per data, in ritardo in cima); **filtri** per tipo (incidenti, policy, rischi, formazione, NC/CAPA, stakeholder, audit, riesame, revisioni) e per stato.
|
||||
- Click su evento → deep-link al modulo sorgente (es. incidente, policy, audit…).
|
||||
- Legenda + badge "in ritardo / in scadenza". Voce sidebar ("Calendario") in `common-bi.js`+`common.js`; help/i18n/KB.
|
||||
- La dashboard mostra già "prossime scadenze": aggiungere un link "Apri calendario".
|
||||
|
||||
## Ancoraggio
|
||||
Strumento operativo trasversale; supporta direttamente la **buona prassi** di monitoraggio scadenze e revisioni periodiche (ISO 9.1/9.3, NIS2 GV.PO-02/GV.SC-07/DE.CM). Non è un obbligo specifico: è gestione.
|
||||
|
||||
## Stima Modulo C
|
||||
| Fase | Contenuto | Stima |
|
||||
|---|---|---|
|
||||
| **C1** | `CalendarController` (aggregatore union tutte le sorgenti + summary) + router/api | ~0,5 sessione |
|
||||
| **C2** | `calendario.html` (griglia mensile + lista + filtri + deep-link) + sidebar/help/i18n/KB + deploy+smoke | ~0,5–1 sessione |
|
||||
|
||||
**Nessuna migrazione** per C (solo lettura). Le scadenze di A e B vi confluiscono automaticamente.
|
||||
|
||||
## Stima complessiva aggiornata (A + B + C)
|
||||
- Modulo A (Audit interni): ~1 sessione · Modulo B (Riesame): ~1–1,5 · Modulo C (Calendario): ~1 · Verifica flotta finale: ~0,5.
|
||||
- **Totale ~3,5–4 sessioni**, tutto additivo/runner-safe, committato e LIVE a fasi.
|
||||
|
||||
## Ordine consigliato
|
||||
**A → B → C**: il calendario (C) per ultimo così ingloba subito anche le scadenze di Audit interni e Riesame. In alternativa C si può fare per primo come quick-win trasversale (aggrega già tutto l'esistente) e poi A/B vi si agganciano.
|
||||
|
||||
Reference in New Issue
Block a user