@checkstack/notification-backend 0.2.1 → 1.0.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -1,5 +1,184 @@
1
1
  # @checkstack/notification-backend
2
2
 
3
+ ## 1.0.1
4
+
5
+ ### Patch Changes
6
+
7
+ - Updated dependencies [302cd3f]
8
+ - @checkstack/backend-api@0.14.1
9
+ - @checkstack/auth-backend@0.4.23
10
+ - @checkstack/cache-api@0.2.3
11
+ - @checkstack/queue-api@0.2.17
12
+ - @checkstack/auth-common@0.6.4
13
+ - @checkstack/cache-utils@0.2.3
14
+ - @checkstack/common@0.7.0
15
+ - @checkstack/notification-common@1.0.0
16
+ - @checkstack/signal-common@0.2.0
17
+
18
+ ## 1.0.0
19
+
20
+ ### Major Changes
21
+
22
+ - 32d52c6: feat: notification target pattern + per-spec subscriptions
23
+
24
+ Replaces the all-or-nothing catalog system/group notification model with a
25
+ platform-level target pattern. Each notification-emitting plugin declares
26
+ _subscription specs_ against typed _target_ objects exported from the
27
+ target's owning plugin (catalog ships `catalogSystemTarget` and
28
+ `catalogGroupTarget`). Notification-backend handles every per-resource
29
+ group lifecycle, parent-edge inheritance, and legacy-subscription seeding
30
+ — plugins never author groupId helpers, lifecycle hooks, or migration
31
+ code again.
32
+
33
+ **Plugin-author surface area is now ~12 lines per emitter:**
34
+
35
+ ```ts
36
+ // <plugin>-common
37
+ const { defineSubscription } = createSubscriptionFactory(pluginMetadata);
38
+ export const fooSystemSubscription = defineSubscription({
39
+ localId: "system",
40
+ target: catalogSystemTarget,
41
+ display: { title: "Foo Alerts", description: "...", iconName: "Bell" },
42
+ });
43
+
44
+ // <plugin>-backend register()
45
+ env.registerSubscriptionSpecs([fooSystemSubscription]);
46
+ // ^ feeds the plugin loader's dependency sorter — each spec's
47
+ // target.ownerPlugin becomes an implicit init-order dep, so this
48
+ // plugin automatically waits for catalog (the target owner) to
49
+ // finish init + afterPluginsReady before its own runs.
50
+
51
+ // <plugin>-backend afterPluginsReady
52
+ await notificationClient.registerSubscriptionSpec(
53
+ specToRegistration(fooSystemSubscription)
54
+ );
55
+ // dispatch
56
+ await notificationClient.notifyForSubscription({
57
+ specId: fooSystemSubscription.specId,
58
+ resourceKeys: [systemId],
59
+ title,
60
+ body,
61
+ importance,
62
+ action,
63
+ collapseKey,
64
+ subjects,
65
+ });
66
+
67
+ // <plugin>-frontend
68
+ createNotificationSubscriptionExtension({ spec: fooSystemSubscription });
69
+ ```
70
+
71
+ **Migrated plugins**: anomaly, incident, maintenance, healthcheck,
72
+ dependency. Each lost its bespoke `notification-groups.ts`,
73
+ `bootstrap*NotificationGroups`, `ensure*Group`, and inheritance walk —
74
+ all of that is now centralized in notification-backend's
75
+ `subscription-engine`.
76
+
77
+ **Plugin loader change** (`@checkstack/backend-api`,
78
+ `@checkstack/backend`): the register-time API gains
79
+ `env.registerSubscriptionSpecs([...specs])`. The dependency sorter
80
+ walks `spec.target.ownerPlugin` for every declared spec and adds the
81
+ target owner as an init-order dependency of the emitting plugin. This
82
+ guarantees that catalog (the owner of the platform's `system` and
83
+ `group` targets) completes init + afterPluginsReady before any
84
+ emitting plugin tries to register its specs against the notification
85
+ service — no string-prefix heuristics, no manual `dependsOnPlugins`
86
+ list, no stub rows. Plugins that fail to declare their specs at
87
+ register time get a clear `Target type X is not registered. Did the
88
+ emitting plugin declare this spec via env.registerSubscriptionSpecs?`
89
+ error from the dispatcher.
90
+
91
+ **Removed** (no backwards compat):
92
+
93
+ - `catalogClient.notifySystemSubscribers` and
94
+ `catalogClient.notifyManySystemSubscribers`
95
+ - `notificationClient.notifyUsers` and `notificationClient.notifyGroups`
96
+ as direct dispatch primitives — replaced by spec-bound
97
+ `notifyForSubscription`
98
+ - catalog's `bootstrapNotificationGroups` (replaced by
99
+ `bootstrapNotificationTargets`)
100
+
101
+ **Enforcement**: the dispatcher rejects calls referencing unregistered
102
+ specIds, specs owned by other plugins, or resourceKeys that haven't been
103
+ pushed via `upsertNotificationResource`. Display metadata for any
104
+ groupId is recoverable via the spec registry, so audit lists render
105
+ correct labels even when an emitter's frontend isn't loaded.
106
+
107
+ **Per-field anomaly mute** keeps working — it now lives inside the
108
+ generic SubscriptionRow's optional `SubControls` panel
109
+ (`AnomalyFieldMuteList`), exposed through the catalog system detail
110
+ page's notifications card.
111
+
112
+ The catalog system detail page renders a "Notifications" card hosting
113
+ `SystemNotificationSubscriptionsSlot`. The matching group surface is
114
+ not yet rendered — group-level subscriptions are wired end-to-end on
115
+ the backend; a follow-up will add the host UI.
116
+
117
+ **Migration of existing subscribers**: target types declare a
118
+ `legacyGroupIdTemplate`; on first registration of each spec,
119
+ notification-backend reads subscribers from the legacy
120
+ `catalog.system.<id>` / `catalog.group.<id>` groups and seeds the new
121
+ spec groups exactly once per (spec × resource) pair, tracked in
122
+ `subscription_migrations`. Anomaly stays opt-in (its target also
123
+ declares the template, but the user-explicit nature of the original
124
+ opt-in flow means the seeding produces the same set of subscribers
125
+ they already had).
126
+
127
+ ### Minor Changes
128
+
129
+ - 32d52c6: feat(anomaly): per-system and per-field notification mute
130
+
131
+ Anomaly notifications now flow through their own subscription group
132
+ (`anomaly.system.<systemId>`) instead of the shared catalog system group, so
133
+ users can opt out of anomaly noise without losing incident or healthcheck
134
+ alerts for the same system. On first deploy, existing subscribers of each
135
+ `catalog.system.<id>` group are seeded onto the new anomaly group so no one
136
+ silently stops getting alerts.
137
+
138
+ A new mute table (`anomaly_notification_mutes`) backs two granularities:
139
+
140
+ - **Per-field**: silence a single noisy metric on one system.
141
+ - **Per-system**: silence every anomaly for one system in one click.
142
+
143
+ The system anomaly widget now exposes a bell icon on each anomaly row plus a
144
+ `Mute all` toggle in the card header. Mutes are user-scoped and persist
145
+ across sessions.
146
+
147
+ Catalog gains a `systemCreated` hook so anomaly (and any future plugin) can
148
+ provision per-system state on creation rather than waiting for a restart.
149
+ The notification service gains a `bulkSubscribe` service-RPC used by the
150
+ one-time migration described above.
151
+
152
+ - 32d52c6: Bulk notifications affecting multiple systems and collapse lifecycle events into a single card.
153
+
154
+ Notifications now carry an optional `subjects` array (the entities they affect) and an optional `collapseKey` (so related notifications collapse into one row per recipient). Incidents, maintenances, anomalies, healthchecks, and dependency-impact events route through these new fields, so an incident affecting three systems produces one in-app notification + one external send per subscriber instead of three. Lifecycle updates for the same entity (created → updated → resolved) also collapse, with an expandable "+N updates" timeline.
155
+
156
+ Subject kinds are namespaced as `<pluginId>.<localKind>` and built via type-safe helpers exported from each domain's common package (`createSystemSubject`, `incidentCollapseKey`, etc.). The frontend kind registry (`registerSubjectKind`) lets plugins bind icon + label for their kinds; unknown kinds fall back to a generic chip.
157
+
158
+ All notification strategies (SMTP, Slack, Discord, Teams, Telegram, Pushover, Gotify, Webex, Backstage) render the affected subjects natively in their format (HTML cards, Slack blocks, Discord embed fields, adaptive cards, markdown lists, etc.).
159
+
160
+ ### Patch Changes
161
+
162
+ - 32d52c6: Fix and improve password reset flow + email branding:
163
+
164
+ - **Fix**: password reset emails were failing with "Malformed password reset URL: missing token parameter". Better-auth puts the reset token in the URL path (`/reset-password/{token}`), not as a `?token=` query param, so the previous URL-parsing logic always failed. Now uses the `token` argument better-auth passes to `sendResetPassword` directly.
165
+ - **UX**: the reset password page now validates the token on load via a new anonymous `validateResetToken` endpoint, so users see "Invalid Link" / "Link Expired" before typing a password rather than after submitting. Tokens are 24-char nanoid-style values (~143 bits of entropy), so exposing validity does not enable enumeration.
166
+ - **Fix**: transactional notifications were hardcoded to `importance: "critical"`, causing password reset emails to display a misleading "CRITICAL" badge. The `sendTransactional` contract now accepts an optional `importance` field that defaults to `"info"`.
167
+ - **Branding**: redesigned the email layout (`wrapInEmailLayout`) with a Checkstack-style engineering aesthetic — dark header with grid pattern, monospace importance badge, hardened CTA button (Outlook VML fallback + explicit text color), and force-light color scheme to prevent client auto-inversion from breaking text legibility.
168
+
169
+ - Updated dependencies [32d52c6]
170
+ - Updated dependencies [32d52c6]
171
+ - Updated dependencies [32d52c6]
172
+ - Updated dependencies [32d52c6]
173
+ - Updated dependencies [32d52c6]
174
+ - @checkstack/notification-common@1.0.0
175
+ - @checkstack/backend-api@0.14.0
176
+ - @checkstack/auth-backend@0.4.22
177
+ - @checkstack/auth-common@0.6.4
178
+ - @checkstack/cache-api@0.2.2
179
+ - @checkstack/queue-api@0.2.16
180
+ - @checkstack/cache-utils@0.2.2
181
+
3
182
  ## 0.2.1
4
183
 
5
184
  ### Patch Changes
@@ -0,0 +1,3 @@
1
+ ALTER TABLE "notifications" ADD COLUMN "subjects" jsonb;--> statement-breakpoint
2
+ CREATE INDEX IF NOT EXISTS "notifications_user_collapse_idx" ON "notifications" USING btree ("user_id","group_id");--> statement-breakpoint
3
+ CREATE INDEX IF NOT EXISTS "notifications_user_created_idx" ON "notifications" USING btree ("user_id","created_at");
@@ -0,0 +1,46 @@
1
+ CREATE TABLE "notification_resource_parents" (
2
+ "child_target_type_id" text NOT NULL,
3
+ "child_resource_key" text NOT NULL,
4
+ "parent_target_type_id" text NOT NULL,
5
+ "parent_resource_key" text NOT NULL,
6
+ CONSTRAINT "notification_resource_parents_child_target_type_id_child_resource_key_parent_target_type_id_parent_resource_key_pk" PRIMARY KEY("child_target_type_id","child_resource_key","parent_target_type_id","parent_resource_key")
7
+ );
8
+ --> statement-breakpoint
9
+ CREATE TABLE "notification_resources" (
10
+ "target_type_id" text NOT NULL,
11
+ "resource_key" text NOT NULL,
12
+ "display_label" text NOT NULL,
13
+ "upserted_at" timestamp DEFAULT now() NOT NULL,
14
+ CONSTRAINT "notification_resources_target_type_id_resource_key_pk" PRIMARY KEY("target_type_id","resource_key")
15
+ );
16
+ --> statement-breakpoint
17
+ CREATE TABLE "notification_targets" (
18
+ "target_type_id" text PRIMARY KEY NOT NULL,
19
+ "owner_plugin" text NOT NULL,
20
+ "resource_kind" text NOT NULL,
21
+ "parent_target_type_id" text,
22
+ "legacy_group_id_template" text,
23
+ "registered_at" timestamp DEFAULT now() NOT NULL
24
+ );
25
+ --> statement-breakpoint
26
+ CREATE TABLE "subscription_migrations" (
27
+ "spec_id" text NOT NULL,
28
+ "resource_key" text NOT NULL,
29
+ "migrated_at" timestamp DEFAULT now() NOT NULL,
30
+ CONSTRAINT "subscription_migrations_spec_id_resource_key_pk" PRIMARY KEY("spec_id","resource_key")
31
+ );
32
+ --> statement-breakpoint
33
+ CREATE TABLE "subscription_specs" (
34
+ "spec_id" text PRIMARY KEY NOT NULL,
35
+ "owner_plugin" text NOT NULL,
36
+ "local_id" text NOT NULL,
37
+ "target_type_id" text NOT NULL,
38
+ "display_title" text NOT NULL,
39
+ "display_description" text NOT NULL,
40
+ "display_icon_name" text,
41
+ "registered_at" timestamp DEFAULT now() NOT NULL
42
+ );
43
+ --> statement-breakpoint
44
+ ALTER TABLE "notification_resources" ADD CONSTRAINT "notification_resources_target_type_id_notification_targets_target_type_id_fk" FOREIGN KEY ("target_type_id") REFERENCES "notification_targets"("target_type_id") ON DELETE cascade ON UPDATE no action;--> statement-breakpoint
45
+ ALTER TABLE "subscription_specs" ADD CONSTRAINT "subscription_specs_target_type_id_notification_targets_target_type_id_fk" FOREIGN KEY ("target_type_id") REFERENCES "notification_targets"("target_type_id") ON DELETE no action ON UPDATE no action;--> statement-breakpoint
46
+ CREATE INDEX "notification_resource_parents_child_idx" ON "notification_resource_parents" USING btree ("child_target_type_id","child_resource_key");
@@ -0,0 +1,237 @@
1
+ {
2
+ "id": "487b48a4-723f-478c-ab7b-4512c095a7c4",
3
+ "prevId": "5899e448-f29a-46e2-b75d-51c7832c432b",
4
+ "version": "7",
5
+ "dialect": "postgresql",
6
+ "tables": {
7
+ "public.notification_groups": {
8
+ "name": "notification_groups",
9
+ "schema": "",
10
+ "columns": {
11
+ "id": {
12
+ "name": "id",
13
+ "type": "text",
14
+ "primaryKey": true,
15
+ "notNull": true
16
+ },
17
+ "name": {
18
+ "name": "name",
19
+ "type": "text",
20
+ "primaryKey": false,
21
+ "notNull": true
22
+ },
23
+ "description": {
24
+ "name": "description",
25
+ "type": "text",
26
+ "primaryKey": false,
27
+ "notNull": true
28
+ },
29
+ "owner_plugin": {
30
+ "name": "owner_plugin",
31
+ "type": "text",
32
+ "primaryKey": false,
33
+ "notNull": true
34
+ },
35
+ "created_at": {
36
+ "name": "created_at",
37
+ "type": "timestamp",
38
+ "primaryKey": false,
39
+ "notNull": true,
40
+ "default": "now()"
41
+ }
42
+ },
43
+ "indexes": {},
44
+ "foreignKeys": {},
45
+ "compositePrimaryKeys": {},
46
+ "uniqueConstraints": {},
47
+ "policies": {},
48
+ "checkConstraints": {},
49
+ "isRLSEnabled": false
50
+ },
51
+ "public.notification_subscriptions": {
52
+ "name": "notification_subscriptions",
53
+ "schema": "",
54
+ "columns": {
55
+ "user_id": {
56
+ "name": "user_id",
57
+ "type": "text",
58
+ "primaryKey": false,
59
+ "notNull": true
60
+ },
61
+ "group_id": {
62
+ "name": "group_id",
63
+ "type": "text",
64
+ "primaryKey": false,
65
+ "notNull": true
66
+ },
67
+ "subscribed_at": {
68
+ "name": "subscribed_at",
69
+ "type": "timestamp",
70
+ "primaryKey": false,
71
+ "notNull": true,
72
+ "default": "now()"
73
+ }
74
+ },
75
+ "indexes": {},
76
+ "foreignKeys": {
77
+ "notification_subscriptions_group_id_notification_groups_id_fk": {
78
+ "name": "notification_subscriptions_group_id_notification_groups_id_fk",
79
+ "tableFrom": "notification_subscriptions",
80
+ "tableTo": "notification_groups",
81
+ "columnsFrom": [
82
+ "group_id"
83
+ ],
84
+ "columnsTo": [
85
+ "id"
86
+ ],
87
+ "onDelete": "cascade",
88
+ "onUpdate": "no action"
89
+ }
90
+ },
91
+ "compositePrimaryKeys": {
92
+ "notification_subscriptions_user_id_group_id_pk": {
93
+ "name": "notification_subscriptions_user_id_group_id_pk",
94
+ "columns": [
95
+ "user_id",
96
+ "group_id"
97
+ ]
98
+ }
99
+ },
100
+ "uniqueConstraints": {},
101
+ "policies": {},
102
+ "checkConstraints": {},
103
+ "isRLSEnabled": false
104
+ },
105
+ "public.notifications": {
106
+ "name": "notifications",
107
+ "schema": "",
108
+ "columns": {
109
+ "id": {
110
+ "name": "id",
111
+ "type": "uuid",
112
+ "primaryKey": true,
113
+ "notNull": true,
114
+ "default": "gen_random_uuid()"
115
+ },
116
+ "user_id": {
117
+ "name": "user_id",
118
+ "type": "text",
119
+ "primaryKey": false,
120
+ "notNull": true
121
+ },
122
+ "title": {
123
+ "name": "title",
124
+ "type": "text",
125
+ "primaryKey": false,
126
+ "notNull": true
127
+ },
128
+ "body": {
129
+ "name": "body",
130
+ "type": "text",
131
+ "primaryKey": false,
132
+ "notNull": true
133
+ },
134
+ "action": {
135
+ "name": "action",
136
+ "type": "jsonb",
137
+ "primaryKey": false,
138
+ "notNull": false
139
+ },
140
+ "importance": {
141
+ "name": "importance",
142
+ "type": "text",
143
+ "primaryKey": false,
144
+ "notNull": true,
145
+ "default": "'info'"
146
+ },
147
+ "is_read": {
148
+ "name": "is_read",
149
+ "type": "boolean",
150
+ "primaryKey": false,
151
+ "notNull": true,
152
+ "default": false
153
+ },
154
+ "group_id": {
155
+ "name": "group_id",
156
+ "type": "text",
157
+ "primaryKey": false,
158
+ "notNull": false
159
+ },
160
+ "subjects": {
161
+ "name": "subjects",
162
+ "type": "jsonb",
163
+ "primaryKey": false,
164
+ "notNull": false
165
+ },
166
+ "created_at": {
167
+ "name": "created_at",
168
+ "type": "timestamp",
169
+ "primaryKey": false,
170
+ "notNull": true,
171
+ "default": "now()"
172
+ }
173
+ },
174
+ "indexes": {
175
+ "notifications_user_collapse_idx": {
176
+ "name": "notifications_user_collapse_idx",
177
+ "columns": [
178
+ {
179
+ "expression": "user_id",
180
+ "isExpression": false,
181
+ "asc": true,
182
+ "nulls": "last"
183
+ },
184
+ {
185
+ "expression": "group_id",
186
+ "isExpression": false,
187
+ "asc": true,
188
+ "nulls": "last"
189
+ }
190
+ ],
191
+ "isUnique": false,
192
+ "concurrently": false,
193
+ "method": "btree",
194
+ "with": {}
195
+ },
196
+ "notifications_user_created_idx": {
197
+ "name": "notifications_user_created_idx",
198
+ "columns": [
199
+ {
200
+ "expression": "user_id",
201
+ "isExpression": false,
202
+ "asc": true,
203
+ "nulls": "last"
204
+ },
205
+ {
206
+ "expression": "created_at",
207
+ "isExpression": false,
208
+ "asc": true,
209
+ "nulls": "last"
210
+ }
211
+ ],
212
+ "isUnique": false,
213
+ "concurrently": false,
214
+ "method": "btree",
215
+ "with": {}
216
+ }
217
+ },
218
+ "foreignKeys": {},
219
+ "compositePrimaryKeys": {},
220
+ "uniqueConstraints": {},
221
+ "policies": {},
222
+ "checkConstraints": {},
223
+ "isRLSEnabled": false
224
+ }
225
+ },
226
+ "enums": {},
227
+ "schemas": {},
228
+ "sequences": {},
229
+ "roles": {},
230
+ "policies": {},
231
+ "views": {},
232
+ "_meta": {
233
+ "columns": {},
234
+ "schemas": {},
235
+ "tables": {}
236
+ }
237
+ }