feat(notifications): Phase B-2 — per-event-type granular preferences

ordinis-migrations/src/main/resources/db/changelog/changes/0025-notification-prefs-event-type.xml

@@ -0,0 +1,50 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<databaseChangeLog
+    xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
+    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+    xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
+    http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.8.xsd">
+
+  <!-- Phase B-2: per-event-type granularity для notification prefs.
+       Раньше (Phase B / migration 0021-2) prefs хранились (user_id, channel) →
+       enabled — global toggle per channel независимо от типа события.
+       Phase B-2 добавляет event_type column чтобы reviewer мог отключить
+       'RecordDraftSubmitted' emails (queue noise) но оставить
+       'RecordDraftApproved/Rejected' (action confirmations).
+
+       Backward compat: existing rows получают event_type='*' (wildcard).
+       Gate резолвит lookup так:
+         1. Try (user, eventType, channel) → use если найдено
+         2. Fallback к (user, '*', channel) → behaves as Phase B
+         3. Default policy (email ON / express+telegram OFF) если оба missing.
+
+       Drop+recreate PK потому что Liquibase не поддерживает ADD COLUMN TO PK
+       atomically на Postgres. Standard pattern. -->
+
+  <changeSet id="0025-1-notification-prefs-event-type" author="ordinis">
+    <comment>Add event_type column with '*' wildcard default для backward compat</comment>
+
+    <addColumn tableName="user_notification_prefs">
+      <column name="event_type" type="VARCHAR(64)" defaultValue="*">
+        <constraints nullable="false"/>
+      </column>
+    </addColumn>
+
+    <!-- Drop old PK (user_id, channel) — нужно расширить до 3 columns -->
+    <sql>
+      ALTER TABLE user_notification_prefs
+      DROP CONSTRAINT user_notification_prefs_pkey;
+    </sql>
+
+    <!-- New PK (user_id, event_type, channel). Order column: event_type
+         second потому что typical lookup pattern — for one user, fetch
+         all events × channels (single user_id scan, then range over
+         event_type+channel via index). -->
+    <sql>
+      ALTER TABLE user_notification_prefs
+      ADD CONSTRAINT user_notification_prefs_pkey
+      PRIMARY KEY (user_id, event_type, channel);
+    </sql>
+  </changeSet>
+
+</databaseChangeLog>

ordinis-migrations/src/main/resources/db/changelog/master.xml

@@ -34,5 +34,6 @@
   <include file="changes/0022-schema-workflow.xml" relativeToChangelogFile="true"/>
   <include file="changes/0023-user-display-cache.xml" relativeToChangelogFile="true"/>
   <include file="changes/0024-notification-read-state.xml" relativeToChangelogFile="true"/>
+  <include file="changes/0025-notification-prefs-event-type.xml" relativeToChangelogFile="true"/>
 
 </databaseChangeLog>