# OHS Alert Rule Task Stubs

These tasks outline how to implement configurable alert recipients for incident submissions. Rules match an incident's **type**, **severity** and **location**. Multiple recipients can be linked to a rule with optional email, SMS and push channels.

:::task-stub{title="Create alert rule table"}
1. Replace the previous three-table design with a single `incident_alert_rules` table.
2. Columns include `incident_type_id`, `severity`, **`location_id`** for optional scoping, recipient info (`send_alert_to`, `email`, `phone`) and the notification flags.
3. Drop `ohs_alert_rules`, `alert_recipients` and `ohs_alert_rules2alert_recipients` in the migration.
4. Update `TAFDB.sql` and `TAFDB.pgsql` with the new definition.
:::

:::task-stub{title="Expose alert rule API"}
1. Create `models/incident_alert_rules.php` describing the table fields.
2. Sync the table through `/api/sync` using `LocalSyncManager`. A dedicated
   controller is only required if additional business logic is needed.
3. Provide PHPUnit tests for basic CRUD using the sync endpoints.
:::

:::task-stub{title="Configure workflow notifications"}
1. Import a workflow file (e.g. `docs/ohs_incident_alert_workflow.json`) that listens to `ohs.incidentCreated`.
2. Add a step that queries `incident_alert_rules` to fetch matching recipients based on the incident's type and severity.
3. For each recipient use `condition` steps checking `send_email`, `send_sms` and `send_push` before the respective `email`, `sms` or `alert` steps.
4. `user_id` should normally be present for push alerts but may be `NULL` when notifying external contacts; document this nullable field in the workflow file.
:::

> **Note**: Alert recipients are now loaded using `query_records` and processed
> with `for_each_record` instead of the previous custom step. Update any
> existing workflows to use this pattern.