From 24e1525e4f78d7457eb46d965d08183fe7bb50e3 Mon Sep 17 00:00:00 2001 From: Ruben Fiszel Date: Tue, 4 Aug 2026 07:43:39 +0000 Subject: [PATCH] docs: describe the trigger as it is --- .../20260802172300_notify_user_email_change.up.sql | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/backend/migrations/20260802172300_notify_user_email_change.up.sql b/backend/migrations/20260802172300_notify_user_email_change.up.sql index 5e84ccc899..ed2162b364 100644 --- a/backend/migrations/20260802172300_notify_user_email_change.up.sql +++ b/backend/migrations/20260802172300_notify_user_email_change.up.sql @@ -38,18 +38,17 @@ EXECUTE FUNCTION notify_usr_email_change(); -- A superadmin acting outside their workspaces resolves through `password` instead, and that row -- names no workspace of its own. The `*:` payload says so: the reader drops that name's entry in -- every workspace rather than the whole cache, which would undo the caching on an instance that --- rewrites these rows in bulk. `COALESCE(username, email)` is the name a principal can hold, --- matching `permissioned_as_from_email`. Confined to superadmins because they are the only --- accounts the `usr` triggers above cannot cover. +-- rewrites these rows in bulk. Confined to superadmins because they are the only accounts the +-- `usr` triggers above cannot cover. CREATE OR REPLACE FUNCTION notify_superadmin_identity_change() RETURNS TRIGGER AS $$ DECLARE names TEXT[] := '{}'; BEGIN - -- Both columns, not `COALESCE`: `resolve_username_to_email` matches a `u/` principal against - -- `username` OR `email`, and whichever string the caller passed is the key it cached under, - -- so an account with a username can still hold a live entry under its address. Old and new - -- of each, because a change to either leaves the other's entry behind. + -- Every alias the principal can be spelled as: `resolve_username_to_email` matches a `u/` + -- principal against `username` OR `email`, and whichever string the caller passed is the key + -- it cached under, so one account can hold a live entry under either. Old and new of each, + -- because a change to one leaves the other's entry behind. IF TG_OP <> 'DELETE' THEN names := names || ARRAY[NEW.username, NEW.email]; END IF; IF TG_OP <> 'INSERT' THEN names := names || ARRAY[OLD.username, OLD.email]; END IF; INSERT INTO notify_event (channel, payload)