From 8d7aaad9a8cf0a141eae42975749a6c74fa90469 Mon Sep 17 00:00:00 2001
From: npeter83 <npeter83+claude@gmail.com>
Date: Tue, 1 Sep 2026 23:50:29 +0200
Subject: [PATCH] =?UTF-8?q?fix:=20warn=20before=20the=20delete,=20not=20af?=
 =?UTF-8?q?ter=20=E2=80=94=20plus=20round-2=20copy=20and=20a11y=20correcti?=
 =?UTF-8?q?ons?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Round 2 on the feature diff (15 → 12):

- still_allowed_by_env now rides the invite LIST as well as the delete response,
  so the confirmation warns while the admin can still change their mind. It
  mattered most for a DENIED row on an env-allow-listed address: deleting it
  silently converted a refusal into a grant, and the only warning arrived after
  the irreversible click.
- Both inbox bodies claimed to name "the most recent" dropped message. The
  throttle records the FIRST of each hour and never updates it, so they now say
  "one of them", and the not-configured body finally names where to fix it.
- settings.invites.emailOff told the admin they "get no notice when someone
  signs up" — rendered directly above the queue that shows exactly that. Only
  the email is lost, and it now says so.
- The disabled delete buttons put their reason out of reach: `disabled` drops a
  control from the tab order and suppresses its title. Switched to
  aria-disabled + preventDefault, the pattern Playlists.tsx already established
  for the same reason.
- deleteInvite is quiet, so the 409 the UI handles with a translated toast no
  longer also raises the server's English detail as a modal.
- After a completed password reset, Back landed on the reset form again with a
  consumed token — the history change made that state reachable. The token is
  cleared on success so the reset view stops being the card's root.
- The hu deleteHasAccount named a tab that renders under a different label.

Tests: a dom test for the Access-requests panel covering both has_account
variants and all three delete outcomes, /api/me flag cases, an ADMIN_EMAILS
case, and the env-allowlist test now patches the raw setting so the parsing
stays under test.
---
 backend/app/routes/admin.py                   |  14 +-
 backend/tests/test_admin_invites.py           |  25 ++-
 frontend/src/components/AdminUsers.tsx        |  20 +-
 frontend/src/components/Welcome.tsx           |   5 +-
 .../src/components/adminInvites.dom.test.tsx  | 192 ++++++++++++++++++
 frontend/src/i18n/locales/en/inbox.json       |   4 +-
 frontend/src/i18n/locales/en/settings.json    |   5 +-
 frontend/src/i18n/locales/hu/inbox.json       |   4 +-
 frontend/src/i18n/locales/hu/settings.json    |   7 +-
 frontend/src/lib/api/admin.ts                 |   7 +-
 frontend/src/lib/releaseNotes.ts              |   4 +-
 11 files changed, 264 insertions(+), 23 deletions(-)
 create mode 100644 frontend/src/components/adminInvites.dom.test.tsx

diff --git a/backend/app/routes/admin.py b/backend/app/routes/admin.py
index 8ef7cc84..70ee72f6 100644
--- a/backend/app/routes/admin.py
+++ b/backend/app/routes/admin.py
@@ -44,6 +44,14 @@ def _accounts_for(db: Session, emails: Iterable[str]) -> set[str]:
     return {e.lower() for e in rows if e}
 
 
+def _env_allowed(email: str) -> bool:
+    """Whether the env bootstrap lists still let this address in. `is_allowed` consults them only
+    when no Invite row exists, so this is exactly what deleting the row would fall back to — and the
+    admin has to know that BEFORE they confirm, not from a toast afterwards."""
+    email = (email or "").lower()
+    return email in settings.allowed_email_set or email in settings.admin_email_set
+
+
 def _serialize(inv: Invite, *, has_account: bool = False) -> dict:
     return {
         "id": inv.id,
@@ -55,6 +63,9 @@ def _serialize(inv: Invite, *, has_account: bool = False) -> dict:
         "decided_by": inv.decided_by,
         # Drives the delete affordance: an entry backed by an account is not removable here.
         "has_account": has_account,
+        # …and whether removing it would actually take access away, or leave the env allow-list
+        # granting it anyway (for an ADMIN_EMAILS address, as an admin).
+        "still_allowed_by_env": _env_allowed(inv.email),
     }
 
 
@@ -197,8 +208,7 @@ def delete_invite(
             status_code=409,
             detail="That address already has an account — delete the account instead.",
         )
-    email = (inv.email or "").lower()
-    still_allowed_by_env = email in settings.allowed_email_set or email in settings.admin_email_set
+    still_allowed_by_env = _env_allowed(inv.email)
     audit.record(
         db,
         admin.id,
diff --git a/backend/tests/test_admin_invites.py b/backend/tests/test_admin_invites.py
index 0cc31906..96d35173 100644
--- a/backend/tests/test_admin_invites.py
+++ b/backend/tests/test_admin_invites.py
@@ -86,20 +86,37 @@ def test_deleting_an_env_allow_listed_address_reports_that_it_kept_access(
     # no invite exists. The admin has to be told, or they think they removed access and did not.
     from app.config import settings
 
-    monkeypatch.setattr(
-        type(settings), "allowed_email_set", property(lambda self: {"ops@example.com"})
-    )
+    # Patch the raw env field, not the derived property: that keeps the split/strip/lower parsing
+    # under test, and matches how the rest of the suite stubs settings.
+    monkeypatch.setattr(settings, "allowed_emails", " OPS@Example.com , someone@else.test ")
     admin = make_user(email="admin@example.com", role="admin")
     db.add(Invite(email="ops@example.com", status="approved", decided_by=admin.email))
     db.commit()
     client = as_user(admin)
+    listed = _invites(client)["ops@example.com"]
+    # The LIST carries it too, so the confirm dialog can warn before the delete happens.
+    assert listed["still_allowed_by_env"] is True
 
-    r = client.delete(f"/api/admin/invites/{_invites(client)['ops@example.com']['id']}")
+    r = client.delete(f"/api/admin/invites/{listed['id']}")
 
     assert r.status_code == 200
     assert r.json()["still_allowed_by_env"] is True
 
 
+def test_an_admin_emails_address_is_also_reported(db, make_user, as_user, monkeypatch):
+    # ADMIN_EMAILS is the sharper case: deleting the row not only keeps access, the next Google
+    # sign-in re-promotes the address to admin.
+    from app.config import settings
+
+    monkeypatch.setattr(settings, "admin_emails", "boss@example.com")
+    admin = make_user(email="admin@example.com", role="admin")
+    db.add(Invite(email="boss@example.com", status="approved", decided_by=admin.email))
+    db.commit()
+    client = as_user(admin)
+
+    assert _invites(client)["boss@example.com"]["still_allowed_by_env"] is True
+
+
 def test_deleting_a_pending_request_forgets_it(db, make_user, as_user):
     # A pending row is deletable too — "not now, and don't keep the record" is a different decision
     # from Deny, which keeps the row precisely so the person cannot immediately re-ask.
diff --git a/frontend/src/components/AdminUsers.tsx b/frontend/src/components/AdminUsers.tsx
index 807341cb..1cbb78c7 100644
--- a/frontend/src/components/AdminUsers.tsx
+++ b/frontend/src/components/AdminUsers.tsx
@@ -322,10 +322,17 @@ function AdminInvites() {
       if (conflict) refresh();
     },
   });
-  const onDelete = async (i: { id: number; email: string }) => {
+  const onDelete = async (i: Invite) => {
     const ok = await confirm({
       title: t("settings.invites.deleteTitle"),
-      message: t("settings.invites.deleteConfirm", { email: i.email }),
+      // Removing the row is not a revoke when the address is also in the server's env allow-lists —
+      // say so while the admin can still change their mind, not in a toast after the fact.
+      message: t(
+        i.still_allowed_by_env
+          ? "settings.invites.deleteConfirmStillAllowed"
+          : "settings.invites.deleteConfirm",
+        { email: i.email },
+      ),
       confirmLabel: t("settings.invites.delete"),
       danger: true,
     });
@@ -410,9 +417,12 @@ function AdminInvites() {
                 {/* An entry with an account behind it stays read-only: deleting it would revoke that
                     user's access, since is_allowed reads this row. Delete the user instead. */}
                 {i.has_account ? (
+                  // `disabled` would drop it from the tab order AND suppress the title, so the
+                  // reason reached nobody — same call as the Playlists drag handle.
                   <button
                     type="button"
-                    disabled
+                    aria-disabled
+                    onClick={(e) => e.preventDefault()}
                     title={t("settings.invites.deleteHasAccount")}
                     aria-label={t("settings.invites.deleteHasAccount")}
                     className="shrink-0 p-1 text-muted/50 cursor-not-allowed"
@@ -615,9 +625,11 @@ function InviteRow({
           instead — shown as a disabled control rather than omitted, or the admin sees a row that is
           silently missing a button their other rows have. */}
       {inv.has_account ? (
+        // aria-disabled, not `disabled`: the reason has to stay reachable by keyboard.
         <button
           type="button"
-          disabled
+          aria-disabled
+          onClick={(e) => e.preventDefault()}
           title={t("settings.invites.deleteHasAccount")}
           aria-label={t("settings.invites.deleteHasAccount")}
           className="shrink-0 p-1.5 rounded-lg border border-border/50 text-muted/50 cursor-not-allowed"
diff --git a/frontend/src/components/Welcome.tsx b/frontend/src/components/Welcome.tsx
index 835ad1ec..3bded0d8 100644
--- a/frontend/src/components/Welcome.tsx
+++ b/frontend/src/components/Welcome.tsx
@@ -309,7 +309,9 @@ function AuthCard() {
   // stay in the query string.
   const [params] = useState(() => new URLSearchParams(window.location.search));
   const [hashParams] = useState(() => new URLSearchParams(window.location.hash.replace(/^#/, "")));
-  const resetToken = hashParams.get("reset");
+  // State, not a const: once the token has been spent the reset view must stop being the card's
+  // root, or a Back from the "password changed" screen lands on a form whose token is already used.
+  const [resetToken, setResetToken] = useState<string | null>(() => hashParams.get("reset"));
   const verifyToken = hashParams.get("verify"); // raw token → POST to confirm (new flow)
   const bounced = params.get("access"); // Google denied → "requested" | "denied"
   const deleted = params.get("deleted"); // self-service account deletion just completed
@@ -423,6 +425,7 @@ function AuthCard() {
         setDone(t("welcome.auth.resendDone"));
       } else if (mode === "reset") {
         await api.confirmPasswordReset(resetToken ?? "", password);
+        setResetToken(null); // single-use: the reset view is no longer a place to come back to
         setDone(t("welcome.auth.resetDone"));
       }
     } catch (err) {
diff --git a/frontend/src/components/adminInvites.dom.test.tsx b/frontend/src/components/adminInvites.dom.test.tsx
new file mode 100644
index 00000000..41686a1f
--- /dev/null
+++ b/frontend/src/components/adminInvites.dom.test.tsx
@@ -0,0 +1,192 @@
+// @vitest-environment jsdom
+//
+// The Access-requests panel's delete affordance and its three outcomes. The control's whole point is
+// that it explains itself: an entry backed by an account keeps a focusable, labelled control instead
+// of quietly missing one, and an address the server's env still allow-lists gets a warning BEFORE the
+// irreversible click, not a correction after it.
+//
+// i18n is a key-passthrough so assertions read stable keys; the API and the confirm/notify
+// singletons are stubbed so the panel can be driven without a server.
+import { describe, it, expect, afterEach, beforeEach, vi } from "vitest";
+import { render, screen, cleanup, waitFor, fireEvent } from "@testing-library/react";
+import { QueryClient, QueryClientProvider } from "@tanstack/react-query";
+
+vi.mock("react-i18next", async (importOriginal) => {
+  const actual = await importOriginal<typeof import("react-i18next")>();
+  return {
+    ...actual,
+    useTranslation: () => ({
+      // Echo the interpolation too, so a message that forgets its {{email}} is visible in the test.
+      t: (key: string, vars?: Record<string, unknown>) =>
+        vars?.email ? `${key}:${String(vars.email)}` : key,
+      i18n: { language: "en" },
+    }),
+  };
+});
+
+type ConfirmOpts = { title?: string; message?: string; confirmLabel?: string; danger?: boolean };
+const confirmMock = vi.fn(async (_opts: ConfirmOpts) => true);
+vi.mock("./ConfirmProvider", () => ({
+  useConfirm: () => confirmMock,
+  ConfirmProvider: ({ children }: { children: React.ReactNode }) => children,
+}));
+
+const notifyMock = vi.fn();
+vi.mock("../lib/notifications", async (importOriginal) => {
+  const actual = await importOriginal<typeof import("../lib/notifications")>();
+  return { ...actual, notify: (...a: unknown[]) => notifyMock(...a) };
+});
+
+const meMock = { pending_invites: 0, email_configured: true, id: 1, role: "admin" };
+vi.mock("../lib/useMe", () => ({ useMe: () => meMock }));
+
+// The tab strip is rendered into an app-level toolbar slot that does not exist here, so pin the
+// active tab directly — this file is about the Access-requests panel, not the tab chrome.
+vi.mock("./Tabs", () => ({
+  default: () => null,
+  usePersistedTab: () => ["access", () => {}],
+}));
+
+const listMock = vi.fn();
+const deleteMock = vi.fn();
+vi.mock("../lib/api", async (importOriginal) => {
+  const actual = await importOriginal<typeof import("../lib/api")>();
+  return {
+    ...actual,
+    api: {
+      ...actual.api,
+      adminInvites: () => listMock(),
+      deleteInvite: (id: number) => deleteMock(id),
+    },
+  };
+});
+
+import { HttpError } from "../lib/api";
+import AdminUsers from "./AdminUsers";
+
+const invite = (over: Partial<Record<string, unknown>> = {}) => ({
+  id: 1,
+  email: "asker@example.com",
+  status: "pending",
+  note: null,
+  requested_at: null,
+  decided_at: null,
+  decided_by: null,
+  has_account: false,
+  still_allowed_by_env: false,
+  ...over,
+});
+
+const renderPanel = () => {
+  const qc = new QueryClient({ defaultOptions: { queries: { retry: false } } });
+  return render(
+    <QueryClientProvider client={qc}>
+      <AdminUsers />
+    </QueryClientProvider>,
+  );
+};
+
+beforeEach(() => {
+  confirmMock.mockClear().mockResolvedValue(true);
+  notifyMock.mockClear();
+  deleteMock.mockReset().mockResolvedValue({ deleted: 1, still_allowed_by_env: false });
+  listMock.mockReset().mockResolvedValue([invite()]);
+  meMock.email_configured = true;
+});
+afterEach(cleanup);
+
+const openAccessTab = async () => {
+  await screen.findByText("settings.invites.title");
+};
+
+describe("Access requests — the delete affordance", () => {
+  it("offers a labelled delete on an entry with no account behind it", async () => {
+    renderPanel();
+    await openAccessTab();
+
+    const btn = await screen.findByLabelText("settings.invites.deleteLabel:asker@example.com");
+    expect(btn.getAttribute("aria-disabled")).toBeNull();
+  });
+
+  it("keeps the control present and focusable — not missing — when the address has an account", async () => {
+    listMock.mockResolvedValue([invite({ has_account: true })]);
+    renderPanel();
+    await openAccessTab();
+
+    const btn = await screen.findByLabelText("settings.invites.deleteHasAccount");
+    // aria-disabled, not `disabled`: a disabled button leaves the tab order and takes its
+    // explanation with it, which is the whole reason the control is shown at all.
+    expect(btn.getAttribute("aria-disabled")).toBe("true");
+    expect((btn as HTMLButtonElement).disabled).toBe(false);
+    expect(btn.getAttribute("title")).toBe("settings.invites.deleteHasAccount");
+    expect(screen.queryByLabelText(/deleteLabel/)).toBeNull();
+  });
+
+  it("warns in the confirmation — before the click is irreversible — when the env still allows it", async () => {
+    listMock.mockResolvedValue([invite({ still_allowed_by_env: true })]);
+    renderPanel();
+    await openAccessTab();
+
+    fireEvent.click(await screen.findByLabelText("settings.invites.deleteLabel:asker@example.com"));
+
+    expect(confirmMock).toHaveBeenCalledTimes(1);
+    expect(confirmMock.mock.calls[0]![0]).toMatchObject({
+      message: "settings.invites.deleteConfirmStillAllowed:asker@example.com",
+      danger: true,
+    });
+  });
+
+  it("uses the plain confirmation otherwise", async () => {
+    renderPanel();
+    await openAccessTab();
+
+    fireEvent.click(await screen.findByLabelText("settings.invites.deleteLabel:asker@example.com"));
+
+    expect(confirmMock.mock.calls[0]![0]).toMatchObject({
+      message: "settings.invites.deleteConfirm:asker@example.com",
+    });
+  });
+
+  it("says the entry kept its access when the server reports the env allow-list", async () => {
+    deleteMock.mockResolvedValue({ deleted: 1, still_allowed_by_env: true });
+    renderPanel();
+    await openAccessTab();
+
+    fireEvent.click(await screen.findByLabelText("settings.invites.deleteLabel:asker@example.com"));
+
+    await waitFor(() =>
+      expect(notifyMock).toHaveBeenCalledWith({
+        level: "warning",
+        message: "settings.invites.deletedStillAllowed",
+      }),
+    );
+  });
+
+  it("turns a 409 into the actionable reason rather than a generic failure", async () => {
+    // The stale-list case: someone registered on the address after the page loaded.
+    deleteMock.mockRejectedValue(new HttpError(409, "That address already has an account"));
+    renderPanel();
+    await openAccessTab();
+
+    fireEvent.click(await screen.findByLabelText("settings.invites.deleteLabel:asker@example.com"));
+
+    await waitFor(() =>
+      expect(notifyMock).toHaveBeenCalledWith({
+        level: "error",
+        message: "settings.invites.deleteHasAccount",
+      }),
+    );
+  });
+
+  it("shows the mail-is-off warning only while email is unconfigured", async () => {
+    renderPanel();
+    await openAccessTab();
+    expect(screen.queryByText("settings.invites.emailOff")).toBeNull();
+    cleanup();
+
+    meMock.email_configured = false;
+    renderPanel();
+    await openAccessTab();
+    expect(await screen.findByText("settings.invites.emailOff")).toBeTruthy();
+  });
+});
diff --git a/frontend/src/i18n/locales/en/inbox.json b/frontend/src/i18n/locales/en/inbox.json
index 264fdbd8..1373bb92 100644
--- a/frontend/src/i18n/locales/en/inbox.json
+++ b/frontend/src/i18n/locales/en/inbox.json
@@ -31,7 +31,7 @@
   },
   "emailUndelivered": {
     "title": "Email is not going out",
-    "notConfigured": "SMTP is not configured, so nothing this instance sends is being delivered — verification links, password resets and access requests alike. The most recent was “{{subject}}”.",
-    "sendFailed": "The mail server rejected a message, so deliveries are failing — the most recent was “{{subject}}”. Check Configuration → Email / SMTP and send a test."
+    "notConfigured": "SMTP is not configured, so nothing this instance sends is being delivered — verification links, password resets and access requests alike. One of them was “{{subject}}”. Set it up under Configuration → Email / SMTP.",
+    "sendFailed": "The mail server rejected a message, so deliveries are failing. One of them was “{{subject}}”. Check Configuration → Email / SMTP and send a test."
   }
 }
diff --git a/frontend/src/i18n/locales/en/settings.json b/frontend/src/i18n/locales/en/settings.json
index b5dbc213..6778ac43 100644
--- a/frontend/src/i18n/locales/en/settings.json
+++ b/frontend/src/i18n/locales/en/settings.json
@@ -173,7 +173,8 @@
     "deleteHasAccount": "Someone has registered on this address — manage it under Users & roles, where deleting the account removes this entry too.",
     "deleted": "Whitelist entry removed.",
     "deleteFailed": "Could not remove the entry.",
-    "emailOff": "Email sending is not configured, so nobody gets a verification link and you get no notice when someone signs up. Fix it under Configuration → Email / SMTP.",
-    "deletedStillAllowed": "Entry removed, but this address is still allow-listed by the server's configuration, so it keeps access. Remove it from ALLOWED_EMAILS / ADMIN_EMAILS to change that."
+    "emailOff": "Email sending is not configured, so nobody gets a verification link and no request reaches you by email — you will only see sign-ups in this list. Fix it under Configuration → Email / SMTP.",
+    "deletedStillAllowed": "Entry removed, but this address is still allow-listed by the server's configuration, so it keeps access. Remove it from ALLOWED_EMAILS / ADMIN_EMAILS to change that.",
+    "deleteConfirmStillAllowed": "Forget {{email}}? Careful: this address is also allow-listed in the server's configuration (ALLOWED_EMAILS / ADMIN_EMAILS), so removing this row will NOT take its access away — and an ADMIN_EMAILS address is made an admin again on its next sign-in."
   }
 }
diff --git a/frontend/src/i18n/locales/hu/inbox.json b/frontend/src/i18n/locales/hu/inbox.json
index d812f38c..c5b82165 100644
--- a/frontend/src/i18n/locales/hu/inbox.json
+++ b/frontend/src/i18n/locales/hu/inbox.json
@@ -31,7 +31,7 @@
   },
   "emailUndelivered": {
     "title": "Nem megy ki e-mail",
-    "notConfigured": "Az SMTP nincs beállítva, így semmi nem kézbesíthető, amit ez a példány küldene — megerősítő linkek, jelszó-visszaállítások és hozzáférés-kérelmek egyaránt. A legutóbbi: „{{subject}}”.",
-    "sendFailed": "A levelezőszerver visszautasított egy üzenetet, tehát a kézbesítés hibára fut — a legutóbbi: „{{subject}}”. Nézd meg a Konfiguráció → E-mail / SMTP fület, és küldj tesztet."
+    "notConfigured": "Az SMTP nincs beállítva, így semmi nem kézbesíthető, amit ez a példány küldene — megerősítő linkek, jelszó-visszaállítások és hozzáférés-kérelmek egyaránt. Az egyik ilyen: „{{subject}}”. Állítsd be a Konfiguráció → E-mail / SMTP fülön.",
+    "sendFailed": "A levelezőszerver visszautasított egy üzenetet, tehát a kézbesítés hibára fut. Az egyik ilyen: „{{subject}}”. Nézd meg a Konfiguráció → E-mail / SMTP fület, és küldj tesztet."
   }
 }
diff --git a/frontend/src/i18n/locales/hu/settings.json b/frontend/src/i18n/locales/hu/settings.json
index 27277382..f6f80d3e 100644
--- a/frontend/src/i18n/locales/hu/settings.json
+++ b/frontend/src/i18n/locales/hu/settings.json
@@ -170,10 +170,11 @@
     "deleteHint": "A cím elfelejtése. Egy későbbi kérelme új kérelemként jelenik meg.",
     "deleteTitle": "Törlöd a whitelista-bejegyzést?",
     "deleteConfirm": "Elfelejted {{email}} címet? A Siftlode eldobja a bejegyzést, a korábban megadott jóváhagyással együtt, így az adott címről újra kérelmezni kell.",
-    "deleteHasAccount": "Erre a címre már regisztrált valaki — a Felhasználók és szerepkörök fülön kezelhető, ahol a fiók törlése ezt a bejegyzést is eltávolítja.",
+    "deleteHasAccount": "Erre a címre már regisztrált valaki — a Felhasználók és szerepek fülön kezelhető, ahol a fiók törlése ezt a bejegyzést is eltávolítja.",
     "deleted": "Whitelista-bejegyzés eltávolítva.",
     "deleteFailed": "A bejegyzést nem sikerült eltávolítani.",
-    "emailOff": "Az e-mail-küldés nincs beállítva, így senki nem kap megerősítő linket, és te sem kapsz értesítést, ha valaki regisztrál. A Konfiguráció → E-mail / SMTP fülön javítható.",
-    "deletedStillAllowed": "A bejegyzés törölve, de ezt a címet a szerver konfigurációja továbbra is engedélyezi, tehát megmarad a hozzáférése. Vedd ki az ALLOWED_EMAILS / ADMIN_EMAILS listából, ha ezen változtatnál."
+    "emailOff": "Az e-mail-küldés nincs beállítva, így senki nem kap megerősítő linket, és e-mailben egy kérelem sem jut el hozzád — a regisztrációkat csak ebben a listában látod. A Konfiguráció → E-mail / SMTP fülön javítható.",
+    "deletedStillAllowed": "A bejegyzés törölve, de ezt a címet a szerver konfigurációja továbbra is engedélyezi, tehát megmarad a hozzáférése. Vedd ki az ALLOWED_EMAILS / ADMIN_EMAILS listából, ha ezen változtatnál.",
+    "deleteConfirmStillAllowed": "Elfelejted {{email}} címet? Figyelem: ezt a címet a szerver konfigurációja is engedélyezi (ALLOWED_EMAILS / ADMIN_EMAILS), így a bejegyzés törlése NEM veszi el a hozzáférését — sőt egy ADMIN_EMAILS cím a következő belépéskor újra adminná válik."
   }
 }
diff --git a/frontend/src/lib/api/admin.ts b/frontend/src/lib/api/admin.ts
index 5bbf960e..2c10790a 100644
--- a/frontend/src/lib/api/admin.ts
+++ b/frontend/src/lib/api/admin.ts
@@ -22,6 +22,9 @@ export interface Invite {
   /** An account already exists for this address, so the entry can't be deleted from here — deleting
    *  it would revoke that user's access (is_allowed reads this row). Delete the user instead. */
   has_account: boolean;
+  /** The address stays allow-listed by the server's env ALLOWED_EMAILS / ADMIN_EMAILS, so removing
+   *  this row would NOT take access away. The delete confirmation says so. */
+  still_allowed_by_env: boolean;
 }
 
 // Admin Configuration page: one DB-overridable setting (registry entry on the backend).
@@ -174,6 +177,8 @@ export const adminApi = {
     req("/api/admin/invites", { method: "POST", body: JSON.stringify({ email }) }),
   /** `still_allowed_by_env` is true when the address stays allow-listed by the server's env
    *  ALLOWED_EMAILS / ADMIN_EMAILS, i.e. removing the row did not actually revoke access. */
+  // quiet: a 409 here ("that address has an account") is a case the UI handles with a translated
+  // toast; without this the shared handler ALSO raises the server's English detail as a modal.
   deleteInvite: (id: number): Promise<{ deleted: number; still_allowed_by_env: boolean }> =>
-    req(`/api/admin/invites/${id}`, { method: "DELETE" }),
+    req(`/api/admin/invites/${id}`, { method: "DELETE" }, { quiet: true }),
 };
diff --git a/frontend/src/lib/releaseNotes.ts b/frontend/src/lib/releaseNotes.ts
index 42bb44d7..035ed7ef 100644
--- a/frontend/src/lib/releaseNotes.ts
+++ b/frontend/src/lib/releaseNotes.ts
@@ -20,8 +20,8 @@ export const RELEASE_NOTES: ReleaseEntry[] = [
     summary:
       "Admins can delete a whitelist entry, and an instance that cannot send email finally says so — in the inbox when a message is dropped, and on the screens where it matters.",
     features: [
-      "Delete an entry under Users → Access requests: an address you whitelisted earlier, or a request nobody has acted on. Deny records your decision and keeps the record; delete forgets the address, and a later request from it arrives as a new one. Entries that already have an account behind them show the control disabled — that row is the account's approval gate, so it is managed from Users & roles, where deleting the account removes the entry too. If the address is also allow-listed in the server's configuration, the confirmation says so, because then removing the entry does not actually take access away.",
-      "When a message cannot go out, every admin gets it in their inbox, naming the most recent message that was lost — an access request, a verification link, a password reset. Sending is deliberately fail-soft so a mail problem never breaks sign-up, but that used to mean it left no trace anywhere. Throttled to one notice an hour, so a dead relay cannot bury the inbox.",
+      "Delete an entry under Users → Access requests: an address you whitelisted earlier, or a request nobody has acted on. Deny records your decision and keeps the record; delete forgets the address, and a later request from it arrives as a new one. Entries that already have an account behind them show the control disabled — that row is the account's approval gate, so it is managed from Users & roles, where deleting the account removes the entry too. If the address is also allow-listed in the server's configuration, the confirmation warns you before you commit, because then removing the entry does not actually take access away.",
+      "When a message cannot go out, every admin gets it in their inbox, naming one of the messages that were lost — an access request, a verification link, a password reset — so you know what your users did not get. Sending is deliberately fail-soft so a mail problem never breaks sign-up, but that used to mean it left no trace anywhere. Throttled to one notice an hour, so a dead relay cannot bury the inbox; the log keeps the full list.",
       "A standing warning where it can be acted on: on Configuration → Email / SMTP while the settings are incomplete, and above the access-request list, where it explains that nobody is getting a verification link and no request will reach you by email.",
     ],
     fixes: [