incident_reporting 1.0.0-alpha2

The data model changed, because the first one was wrong

1.0.0-alpha1 kept a single reporting clock on the incident itself. That can express one jurisdiction's duty and no more.

In practice a single breach at an Indian operator creates four deadlines from one moment of awareness: a CERT-In report due within six hours, and under section 8(6) of the DPDP Act with rule 7 of the Rules, an intimation to each affected Data Principal and an initial description to the Data Protection Board both without delay, followed by a detailed intimation to the Board within seventy-two hours. Two authorities, four clocks. No single timestamp could carry that.

An incident now records only what happened. Each duty arising from it is a separate obligation with its own trigger event, clock start and deadlines. The trigger matters as much as the duration, because regimes do not agree on what starts the clock, and one shared timestamp forced them to pretend they did.

Regimes are plugins

No maintainer can track every statute, so a jurisdiction can be added by another module without touching this one. Every regime must cite the instrument its deadlines come from, and a test enforces that for all regimes present and future.

Deadlines are computed from the plugin on every read rather than stored, so correcting a plugin corrects the historical records instead of leaving a trail of wrong figures behind.

Two regimes ship:

• CERT-In directions — six hours, single stage, triggered by noticing or by being brought to notice.
• DPDP breach intimation — three stages, triggered by becoming aware.

Both were checked against the Gazette rather than against commentary. The seventy-two hours usually attributed to the DPDP Act appears nowhere in it: it is in rule 7(2)(b) of the Rules, G.S.R. 846(E) dated 13 November 2025.

Honest failure modes

An obligation whose regime plugin is missing, because the module providing that jurisdiction was uninstalled, reports no deadline rather than inventing one. An incident with no obligation recorded against it says so plainly on the listing and warns on save, because an empty column would read as nothing to do when what it means is that nobody has yet decided which duties apply.

Upgrading

This release contains update hooks and changes the database schema. Run database updates after deploying.

A CERT-In obligation is created from each existing incident's clock before the old fields are removed, so the data has somewhere to live before the columns go. An incident with no clock start is left alone rather than given an invented trigger time.

Verification

27 tests, 182 assertions, against Drupal 11.4. Fewer tests than the previous release because fourteen covering the old single-clock model were deleted with it.

Still alpha, and still not used in production by anyone.