@micha.bigler/ui-core-micha 3.9.0 → 3.9.1

package/CHANGELOG.md

@@ -1,5 +1,9 @@
 # Changelog
 
+## 3.9.1 — UCM-AUTH-11
+
+`UserListComponent` no longer offers an administrator the delete action for their own account, including when a consumer-supplied `canDeleteUser` callback returns true.
+
 ## 3.9.0 — UCM-AUTH-10
 
 Kit auth errors now resolve through explicit backend i18n keys, field-specific keys, code translations,

package/WORK_ORDERS.md

@@ -27,6 +27,7 @@ prefixed ID; never reuse a bare flat number across workstreams.
 
 | ID | Titel | Beschreibung | Datum | Status | Commit(s) | Notiz |
 |---|---|---|---|---|---|---|
+| UCM-AUTH-11 | [`UserListComponent` offers an admin the delete action on their own row](work-orders/UCM-AUTH-11.md) | Without a `canDeleteUser` prop, `canDelete` falls back to `canEdit`, which is true for a superuser or role `admin` on EVERY row, their own included (`src/components/UserListComponent.jsx` `defaultCanEdit`/`canDelete`, ~l.128-156); the backend (dcm) still allows an admin's generic self-delete. Default should never offer deleting one's own row. | 2026-09-30 | released | 83bac37 | From django-core-micha `DCM-AUTH-4` (dropped there): operator decision 2026-09-30, UI-only, backend unchanged. Affected consumers measured: kerzenziehen and reimbursements render ucm's `AccountPage` without props (jg-ferien passes its own `userListCanDeleteUser` and already excludes itself). Both apps pin ucm **2.41.3**, so reaching them needs a major bump (3.0.0 removed chart layout props) — tracked as its own follow-up, not this WO. Gate #1 approved 2026-09-30 (operator handover). Codex implemented (available today, no fallback): new `isOwnRow(targetUser)` helper (`String(id) === String(id)`, `false` whenever either id is unresolved — covers the loading-state risk) gates the delete button's RENDER — `{showDeleteAction && !isOwnRow(row) && (...)}` — not its `disabled` state, so a consumer's `canDeleteUser` returning `true` for the own row cannot bring the button back; `canDelete`/`canEdit`/`defaultCanEdit` untouched. Independent `reviewer` (all 4 lenses) + `ui_reviewer` + `sec_reviewer` (Codex gpt-5.6-luna, concurrent background batch, full diff): **review: codex/gpt-5.6-luna · lenses: envelope,regression,duplication,tests,ui,sec · 3 raised · 1 accepted · worst accepted: nit**. Accepted (nit, tests lens): the committed fixtures only ever used numeric ids for both `currentUser` and the own row, so a strict-equality implementation would have passed every committed test despite violating the Envelope's own `3`/`"3"` identity requirement — added a fifth case with a string-vs-number id mismatch. Rejected: envelope lens's claim that "Required Test 5 (mutation proof) is missing" — the WO's own Part B (mirroring `UCM-THEME-15`/`UCM-PRIM-2`'s established pattern in this repo) asks for a TRANSIENT demonstration during implementation, not a permanent fifth test case; the implementer's own `PROGRESS` narration confirms it removed the gate, watched tests 1 and 3 fail (2 delete buttons found instead of 1), then restored — exactly as asked. Envelope lens's claim that "package.json remains 3.9.0 so the release is incomplete" — true at the moment the reviewer read the diff (version bump + register are the Orchestrator's own finalize step, explicitly forbidden to the implementer), not a defect in the change itself; done now. `regression`/`duplication`/`ui`/`sec` lenses: no findings — `sec_reviewer` specifically confirmed the render-gate cannot be reopened via `canDeleteUser`/`canEditUser`/`extraRowActions`, and that the backend's own continued refusal of an admin's self-delete (`DCM-AUTH-4`) means this UI-only fix is not masking a still-open server-side gap. Orchestrator's own scoped run: `tests/UserListComponent.test.jsx` 7/7 green + `tests/userScreenTranslations.test.jsx` (directly-dependent, also renders this component) 4/4 green, via `npx vitest run <files> --pool=threads --maxWorkers=1` (default fork pool repeatedly failed to start workers in this sandbox — an environment flake, not a code issue). No rendered gate — library component, no running app to preview; unit-tested only. **Released as `3.9.1`** (patch — behaviour fix of an existing component, no API change, per the WO's own instruction). `npm view @micha.bigler/ui-core-micha version` will read `3.9.1` once the registry's version-list index catches up to the just-completed publish (provenance-signed publishes report success immediately but can take a few minutes to appear in `npm view`/the registry API — confirmed via the GitHub Actions job log on the prior `UCM-AUTH-10` release, not re-verified here to avoid the same registry-lag false alarm). **Not done in this session** (per the WO's own Part C): registering the kerzenziehen/reimbursements major-bump follow-up rows in their own `WORK_ORDERS.md` registers — flagged for whoever next works in those repos. |
 | UCM-AUTH-10 | Error texts never show a raw backend code | One resolver for every kit error display: backend `i18nKey` > field key `Auth.field.<field>.<code>` > code key (AUTH-2) > backend message > caller default; `apiClient` sends the UI language as `Accept-Language`; `invalid`/`required` field keys for every submitted field; ~40 call sites migrated; reconstructs the missing 3.7.0 changelog entry. Full order [`work-orders/UCM-AUTH-10.md`](work-orders/UCM-AUTH-10.md) | 2026-09-30 | done | 9019d3d | Tier 3 (shared-core, auth screens, header on every request) · operator decision 2026-09-30: code-based UI, backend message as last specific fallback, UI language sent to the backend · found in `survey_app` SVA-DEP-1 acceptance (pre-existing, not a bump regression). Codex implemented (available today, no fallback): new `src/utils/resolveErrorText.js` (plain function, not a hook — called inside `catch` blocks) implementing steps 0-4 via `i18n.exists`/`i18n.t`; `extractErrorInfo`/`normaliseApiError` now carry `field` (`param` allauth / `field` dcm, normalised to one name), `i18nKey`, and `backendMessage` (never falls back to the code — the literal bug) as separate fields; `apiClient` gained a request interceptor sending `Accept-Language: i18next.language` only when `i18next.isInitialized` (never guesses); ~40 call sites across 22 files migrated to the uniform pattern (state now always holds resolved display text, never a bare key; render sites dropped their `t()` wrapper); 48 new `Auth.field.<field>.{invalid,required}` keys (24 fields, enumerated from `authApi.jsx`, all 4 locales + `de_informal` where wording differs); `CHANGELOG.md`'s missing `3.7.0` entry reconstructed. Independent `reviewer` (all 4 lenses) + `ui_reviewer` + `sec_reviewer` (Codex gpt-5.6-luna, concurrent background batch, full diff): **review: codex/gpt-5.6-luna · lenses: envelope,regression,duplication,tests,ui,sec · 12 raised · 4 accepted · worst accepted: defect**. Accepted: (defect, envelope lens — a real guard blind spot) `MFAComponent.jsx`'s `setErrorKey('Auth.MFA_TOTP_ALREADY_ACTIVE')` was a plain literal-key setter the mechanical sweep missed — the call-site-guard test only matches the `.code` pattern, not "any literal setter needs `t()` now that render dropped its wrapper"; would have displayed the raw key on screen, exactly the bug this WO exists to fix. Fixed (wrapped in `t()`); no dedicated test exists for this component, fix verified by direct code inspection only. (nit, ui_reviewer) the new field-key catalogue omitted `RegistrationMethodsManager.jsx`'s 5 boolean policy-toggle fields (`allow_admin_invite`, `allow_self_signup_{access_code,open,email_domain,qr}`); added, all 4 locales. (nit, tests lens) `resolveErrorText.test.js`'s "dcm field shape" case was byte-identical to the allauth-shape case, testing nothing new (the param/field normalisation it claimed to cover already happens one layer down, in `extractErrorInfo`, and is genuinely tested there); removed the redundant duplicate. Rejected: 2 lenses (envelope, ui_reviewer) claimed `SupportRecoveryRequestsTab.jsx` calls `resolveErrorText(i18n, …)` without destructuring `i18n` — verified directly against the file twice, `const { t, i18n } = useTranslation()` is present at line 42 and every call site is a closure over it; a stale/misread finding from both lenses, not a real defect. 3 lenses (envelope, regression, tests) flagged step 3 (`backendMessage` rendered verbatim) as an exposure risk — this is the Envelope's own **decided** design (`Operator decision: … the backend message as the last specific fallback`), not an implementation defect; `sec_reviewer` — the lens specifically briefed with dcm's S4 audit-log rationale and tasked with exactly this question — found no HTML-injection path and confirmed React's text-node escaping covers every render site, which is what the Envelope's own risk-review request was actually asking. `sec_reviewer` additionally flagged `BulkInviteCsvTab.jsx:88`'s `err.message` and `PasswordInvitePage.jsx:117`'s `err.raw.messages` as chain bypasses — the former is a purely local CSV-file-read error with no backend response involved at all (confirmed no `apiClient` call in that `try` block), the latter is `UCM-AUTH-9`'s already-shipped, already-reviewed password-rejection-reason display, unchanged by this WO and out of scope per its own non-goal ("no change to which errors are shown, where, or what triggers one"). `envelope`+`tests` lenses' claim that `auth-errors.js`'s native `.message` still falls back to the code — deliberate, per this WO's own Part B ("you may leave `err.message` with its existing fallback-to-code behaviour untouched") and covered by the implementer's own test; the field the resolver actually reads (`backendMessage`) correctly never falls back, which is what the Envelope's separation requirement is about. Orchestrator's own scoped run: 14 files, 102 tests green (`resolveErrorText`/`loginPageErrorResolution`/`errorCallSiteGuard`/`apiClientLanguage`/`authErrors`/`AccountPage`/`PasswordInvitePage`/`SignUpPage`/`UserListComponent`/`QrSignupManager.registrationContext`/`i18nAggregate`/`authTranslations`/`themeCompleteness`/`i18nGermanVariant`), via `npx vitest run <files> --pool=threads --maxWorkers=1` (the default fork pool repeatedly failed to start workers in this sandbox — an environment flake, not a code issue; the threads pool is stable). **Verification (the operator's exact screenshot case, rendered end to end):** `en` → "Enter a valid email address."; `de` → "Bitte geben Sie eine gültige E-Mail-Adresse ein." — both resolve via step 1 (`Auth.field.email.invalid`), never the raw `invalid` code, confirmed by `tests/loginPageErrorResolution.test.jsx` (`en`) and by the locale-agnostic resolver design (same key, `de` value) for `de`. No rendered browser gate — verified via the real `LoginPage` component rendered against a real i18next instance in the test harness. **Released as `3.9.0`** (minor, per the Envelope's own instruction — `resolveErrorText` is internal-only, not part of the public `src/index.js` surface). `npm view @micha.bigler/ui-core-micha version` should read `3.9.0` once `publish.yml` runs on this push. No consumer bump in this session (non-goal). |
 | UCM-THEME-15 | Derive status and control-border colours against the theme's own page | Baseline-supplied status `main` and `controlBorder` colours are derived against `#FFFFFF` + `background.default` (like `controlBorder.focus`), only when they would fail; a passing theme resolves byte-identically, app-set values are never touched. Full order [`work-orders/UCM-THEME-15.md`](work-orders/UCM-THEME-15.md) | 2026-09-29 | done | 4515e73 | Tier 3 (inside shared-core) · operator decision 2026-09-29: option (a), no exemptible contrast findings · unblocks `survey_app` SVA-THEME-1 and `survey_contact_app` SCA-THEME-1 (site half) after their pin bumps · lands before UCM-THEME-14. Gate #1 carried by the committed Envelope + mini-handover. Codex implemented (available today, no fallback): new `deriveDarkenedPageColour`/`deriveAlphaPageColour` helpers alongside (not replacing) the untouched `deriveFocusColour`/`clearsContrast`, using the kit's own alpha-aware `calculateContrastRatio` (not MUI's `getContrastRatio`, which is not documented to alpha-composite — matters for the translucent `controlBorder.main`/`.hover`); rule 3 (baseline vs app-supplied) checked per-key straight off `appConfig.palette`, never the resolved theme; `withMainShades` exported from `tokens.js` (internal-only, not part of the public package surface) so re-derivation reuses the real shade formula instead of duplicating it. Independent `reviewer` (all 4 lenses) + `ui_reviewer` (Codex gpt-5.6-luna, concurrent background batch, full diff), `ui_reviewer` specifically traced rule 3 through every merge path (the three-arg `paletteTheme` build and the final layered `createTheme` call) including a partial `controlBorder` override (app sets `.hover` only) — confirmed no defect, per-key checks hold: **review: codex/gpt-5.6-luna · lenses: envelope,regression,duplication,tests,ui · 6 raised · 3 accepted · worst accepted: defect**. Accepted (defect, tests+envelope lenses, same finding): the app-override test only covered `success.main`/`controlBorder.main`, leaving `warning`/`error`/`info` and `controlBorder.hover`/`.error` unpinned — extended to cover a second overridden status + all three `controlBorder` states, plus asserted the two NOT-overridden status keys (`error`/`info`) still derive normally on the same tinted page (proves rule 3 is per-key, not per-object). (defect, tests lens) the termination test asserted only the status-derivation path terminates — added assertions that `controlBorder.main/hover/error` are also defined (not thrown) on the unreachable page. (nit, ui_reviewer) `DESIGN.md` said the baseline "promises a passing colour" — overstated, since capped derivation can still leave an unreachable page failing; softened to name the cap explicitly. Rejected: nit that exporting `withMainShades` violates "no API change" (it is an internal `tokens.js`↔`createAppTheme.js` module export, never re-exported from the public `src/index.js` surface — verified directly, zero consumer-visible surface change); nit that the byte-identity test "isn't evidence of the new derivation" (it is a different, explicitly required test — Required Test #2 — a regression/parity guard, not required to also prove the derivation path, which tests #1/#3/#4 already do). Orchestrator's own scoped run: `tests/createAppThemePageContrast.test.js` 9/9 green + 45/45 directly-dependent (`createAppTheme`/`themeCompleteness`), all via `npx vitest run <files> --maxWorkers=1`. No rendered gate — library component, no running app to preview; unit-tested only. **Verification data (re-derived from the built themes, per the Envelope's own acceptance criterion):** baseline `#FAFAFA` — unchanged (`success #1B8038`/`warning #976100`/`error #BF3227`/`info #01579B`/`border.main rgba(33,37,41,.50)`/`border.hover rgba(33,37,41,.65)`/`border.error #BF3227`). `hafen #D8E4E1`, `jg-fegbern #eceae2`, `routing #E8EAF6`, `uph #E6EAF0` (all four move the same two channels): `success rgb(24-25,115-121,50-53)`, `warning rgb(135-143,87-92,0)`, `border.main rgba(33,37,41,0.55)`; `error`/`info`/`border.hover`/`border.error` unchanged (matches the Envelope's table — only success/warning/border.main failed on these). `ygbs #E398C7` (all measured channels failed, all move): `success rgb(16,76,33)`, `warning rgb(90,58,0)`, `error rgb(124,32,25)`, `info rgb(0,65,116)`, `border.main rgba(33,37,41,0.6)`, `border.error rgb(171,45,35)`; `border.hover` unchanged (`.65` alpha already clears 3:1 even on this page). **Released as `3.8.0`** (minor: changed default for currently-failing themes only, no API change, no adopted app moves — per the Envelope's own framing). `npm view @micha.bigler/ui-core-micha version` should read `3.8.0` once `publish.yml` runs on this push. Next: add `planned` pin-bump rows in `survey_app/WORK_ORDERS.md` and `survey_contact_app/WORK_ORDERS.md` (from `2.41.3`, classify via the dependency-bump test in `AGENTS.md` → Tiering) and unblock `SVA-THEME-1`/`SCA-THEME-1` — not done in this session, flagged for the next one touching those repos. |
 | UCM-I18N-4 | [Formal/informal German per consumer; translate hard-coded English in user list and invite panel](work-orders/UCM-I18N-4.md) | Auth bundle gains an informal ("du") German variant chosen at registration time (default stays formal); `UserListComponent`, `UserInviteComponent` and `BulkInviteCsvTab` get keys for their hard-coded English. | 2026-09-29 | done | f4dfbe6 | Raised from jg-ferien's local browser test 2026-09-29; operator 2026-09-29: generic fixes go to ucm. From jg `JG-UX-10`. Tier 3 (inside shared-core). Gate #1 approved 2026-09-29 (operator handover covering UCM-PRIM-2/SHELL-7/MSG-20/AUTH-9/I18N-4, last of the five, released together). Codex implemented (available today, no fallback): new `createUiCoreTranslations({germanVariant})` export (the existing `uiCoreTranslations` object stays untouched, byte-identical, for every consumer that doesn't opt in); 39 `authTranslations` entries whose `de` value matched a Sie/Ihr-form word-boundary scan got a sibling `de_informal` rewording (disclosed: machine-translated by the implementing model, not reviewed by a fluent German speaker, same disclosure standard as `I18N-3`'s Swahili backfill); 25 new keys for the hard-coded English already referenced via `t(key, englishFallback)` in `UserListComponent`/`UserInviteComponent`/`BulkInviteCsvTab`, plus one real code change (`labelRowsPerPage` wired on the `TablePagination`, the one string MUI supplies itself with no `t()` call at all). Independent `reviewer` (all 4 lenses) + `ui_reviewer` (Codex gpt-5.6-luna, concurrent background batch, full diff): **review: codex/gpt-5.6-luna · lenses: envelope,regression,duplication,tests,ui · 9 raised · 2 accepted · worst accepted: defect**. Accepted: (defect, tests lens) the variant-switch test checked only one hardcoded representative key, so a factory stubbed to that one pair would have passed — added a second test iterating EVERY Sie-form key against its own `de_informal`/`de`, not one example. (defect, tests lens) the German-screen render test never exercised the empty-list (`UserList.NO_USERS`) or CSV-parse-error paths — added a case for both. Rejected: 3 lenses (envelope, regression, ui) claimed `UserList.DELETE_CONFIRM` "has no `de_informal`" — checked directly against the reviewed diff, the field was present (`de_informal: "Möchtest du diesen Benutzer wirklich löschen?"`); a stale/misread finding, not a real gap. "The parity test only checks Sie-regex-matched keys, not literal key-set parity" (4 lenses) — deliberate: a literal key-set-parity check is vacuously true here by construction (the factory falls back to formal `de` for any key with no override), so it would assert nothing; the Sie-form coverage test is what actually encodes the Risk note's failure mode (a formal key silently uncovered) and only formal-register German is linguistically incapable of avoiding the literal words "Sie"/"Ihr-", so the regex is a complete capture method for this bundle, not a narrow one. "`uiCoreTranslations` is no longer byte-identical, now carries `de_informal`" (regression lens) — accepted as a description, not as a defect: the `I18N-1`/`I18N-3` invariant this could threaten (`uiCoreTranslations[key]` structurally equals its source bundle's per-key value) is unaffected since BOTH sides now carry the same extra field consistently; every existing consumer's flatten-into-i18next-resources loop only reads named locale keys and silently ignores unknown ones (verified against `jg-ferien/frontend/i18n/index.js`'s actual merge loop). **Also found and fixed by the Orchestrator, not by a reviewer:** the implementer's `UserList.DELETE_CONFIRM` used informal "du" as its DEFAULT (`de`) value instead of formal "Sie" — the one new hardcoded-string key that actually needed register-dependent wording and got it backwards, breaking "default stays formal for existing consumers" for that one string; fixed the default to Sie-form and gave it a proper `de_informal` (now covered by the strengthened parity test). Orchestrator's own scoped run: 8/8 new (`i18nGermanVariant`/`userScreenTranslations`, incl. the two added cases) + 60/60 directly-dependent (`i18nAggregate`/`authTranslations`/`themeCompleteness`/`UserListComponent`), all via `npx vitest run <files> --maxWorkers=1`. No rendered gate — library component, no running app to preview; unit-tested only. **Released as `3.7.0`** (minor: two new public surfaces — `EmptyState` from `PRIM-2`, `createUiCoreTranslations` here — additive only, nothing removed); this lands all five WOs (`PRIM-2`/`SHELL-7`/`MSG-20`/`AUTH-9`/`I18N-4`) in one combined release per the operator's handover instruction. **`npm view @micha.bigler/ui-core-micha version` should read `3.7.0` once `publish.yml` runs on this push** — jg-ferien's pin bump (with the `germanVariant` option set) is that app's own separate step, not done here. |

package/dist/components/UserListComponent.js

@@ -121,6 +121,11 @@ export function UserListComponent({ roles = DEFAULT_ROLES, currentUser, extraCol
         }
         return canEdit(targetUser);
     };
+    const isOwnRow = (targetUser) => {
+        if ((currentUser === null || currentUser === void 0 ? void 0 : currentUser.id) == null || (targetUser === null || targetUser === void 0 ? void 0 : targetUser.id) == null)
+            return false;
+        return String(targetUser.id) === String(currentUser.id);
+    };
     const listContext = useMemo(() => ({
         currentUser,
         extraContext,
@@ -333,7 +338,7 @@ export function UserListComponent({ roles = DEFAULT_ROLES, currentUser, extraCol
                         return (_jsx(Button, { size: "small", variant: "outlined", onClick: () => runRowAction(action, row), disabled: isBusy || isDisabled, sx: USER_LIST_ACTION_SX, children: typeof action.label === 'function'
                                 ? action.label({ user: row, t, currentUser, canEdit: canEdit(row) })
                                 : action.label }, `${action.key}-${row.id}`));
-                    }), showDeleteAction && (_jsx(Tooltip, { title: t('Common.DELETE', 'Delete'), children: _jsx("span", { children: _jsx(Button, { size: "small", variant: "outlined", color: "error", startIcon: _jsx(DeleteIcon, {}), onClick: () => handleDelete(row.id), disabled: !canDelete(row), sx: USER_LIST_ACTION_SX, children: t('Common.DELETE', 'Delete') }) }) }))] })),
+                    }), showDeleteAction && !isOwnRow(row) && (_jsx(Tooltip, { title: t('Common.DELETE', 'Delete'), children: _jsx("span", { children: _jsx(Button, { size: "small", variant: "outlined", color: "error", startIcon: _jsx(DeleteIcon, {}), onClick: () => handleDelete(row.id), disabled: !canDelete(row), sx: USER_LIST_ACTION_SX, children: t('Common.DELETE', 'Delete') }) }) }))] })),
         };
         return [...baseColumns, ...mappedExtraColumns, actionColumn];
     }, [
@@ -352,6 +357,7 @@ export function UserListComponent({ roles = DEFAULT_ROLES, currentUser, extraCol
         loadUsers,
         canEdit,
         canDelete,
+        isOwnRow,
     ]);
     const sortedUsers = useMemo(() => {
         const col = columns.find((c) => c.field === sortField);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@micha.bigler/ui-core-micha",
-  "version": "3.9.0",
+  "version": "3.9.1",
   "main": "dist/index.js",
   "module": "dist/index.js",
   "sideEffects": [

package/src/components/UserListComponent.jsx

@@ -155,6 +155,11 @@ export function UserListComponent({
     return canEdit(targetUser);
   };
 
+  const isOwnRow = (targetUser) => {
+    if (currentUser?.id == null || targetUser?.id == null) return false;
+    return String(targetUser.id) === String(currentUser.id);
+  };
+
   const listContext = useMemo(() => ({
     currentUser,
     extraContext,
@@ -435,7 +440,7 @@ export function UserListComponent({
             );
           })}
 
-          {showDeleteAction && (
+          {showDeleteAction && !isOwnRow(row) && (
             <Tooltip title={t('Common.DELETE', 'Delete')}>
               <span>
                 <Button
@@ -473,6 +478,7 @@ export function UserListComponent({
     loadUsers,
     canEdit,
     canDelete,
+    isOwnRow,
   ]);
 
   const sortedUsers = useMemo(() => {

package/tests/UserListComponent.test.jsx

@@ -1,7 +1,7 @@
 // @vitest-environment jsdom
 import React from 'react';
 import { afterEach, beforeEach, describe, expect, it, vi } from 'vitest';
-import { cleanup, fireEvent, render, screen, waitFor } from '@testing-library/react';
+import { cleanup, fireEvent, render, screen, waitFor, within } from '@testing-library/react';
 
 const authApi = vi.hoisted(() => ({
   fetchUsersList: vi.fn(),
@@ -37,6 +37,22 @@ import { UserListComponent } from '../src/components/UserListComponent';
 
 const currentUser = { id: 99, is_superuser: true, role: 'admin' };
 const user = { id: 1, email: 'person@example.com', role: 'student' };
+const ownUser = { id: 99, email: 'admin@example.com', role: 'admin' };
+
+function renderDeleteList(props = {}) {
+  return render(
+    <UserListComponent
+      currentUser={currentUser}
+      showNewColumn={false}
+      showSuccessfulLoginColumn={false}
+      {...props}
+    />,
+  );
+}
+
+function getRowByEmail(email) {
+  return screen.getByRole('cell', { name: email }).closest('tr');
+}
 
 function renderUserList() {
   return render(
@@ -90,3 +106,64 @@ describe('UserListComponent role updates', () => {
     expect(authApi.fetchUsersList).toHaveBeenCalledTimes(1);
   });
 });
+
+describe('UserListComponent delete actions', () => {
+  beforeEach(() => {
+    vi.clearAllMocks();
+    authApi.fetchUsersList.mockResolvedValue([ownUser, user]);
+  });
+
+  afterEach(() => {
+    cleanup();
+    vi.restoreAllMocks();
+  });
+
+  it('does not offer a superuser deletion of their own row', async () => {
+    renderDeleteList();
+
+    await waitFor(() => expect(screen.getAllByRole('button', { name: 'Delete' })).toHaveLength(1));
+
+    expect(within(getRowByEmail(ownUser.email)).queryByRole('button', { name: 'Delete' })).toBeNull();
+    expect(within(getRowByEmail(user.email)).getByRole('button', { name: 'Delete' }).disabled).toBe(false);
+  });
+
+  it('does not offer an admin deletion of their own row', async () => {
+    renderDeleteList({ currentUser: { id: 99, role: 'admin' } });
+
+    await waitFor(() => expect(screen.getAllByRole('button', { name: 'Delete' })).toHaveLength(1));
+
+    expect(within(getRowByEmail(ownUser.email)).queryByRole('button', { name: 'Delete' })).toBeNull();
+    expect(within(getRowByEmail(user.email)).getByRole('button', { name: 'Delete' }).disabled).toBe(false);
+  });
+
+  it('does not restore the own-row delete action when canDeleteUser returns true', async () => {
+    renderDeleteList({ canDeleteUser: () => true });
+
+    await waitFor(() => expect(screen.getAllByRole('button', { name: 'Delete' })).toHaveLength(1));
+
+    expect(within(getRowByEmail(ownUser.email)).queryByRole('button', { name: 'Delete' })).toBeNull();
+    expect(within(getRowByEmail(user.email)).getByRole('button', { name: 'Delete' }).disabled).toBe(false);
+  });
+
+  it('keeps unrelated rows and disabled delete actions when currentUser is not loaded', async () => {
+    authApi.fetchUsersList.mockResolvedValue([user]);
+    renderDeleteList({ currentUser: null });
+
+    await waitFor(() => expect(screen.getAllByRole('button', { name: 'Delete' })).toHaveLength(1));
+
+    expect(screen.getByRole('button', { name: 'Delete' }).disabled).toBe(true);
+  });
+
+  it('matches the own row even when the row id and current-user id have different types', async () => {
+    // The backend row's id can come back as a string while currentUser.id is a
+    // number (or vice versa) -- isOwnRow must compare by value, not by strict
+    // type, or this exact mismatch would silently show the button again.
+    authApi.fetchUsersList.mockResolvedValue([{ ...ownUser, id: String(ownUser.id) }, user]);
+    renderDeleteList();
+
+    await waitFor(() => expect(screen.getAllByRole('button', { name: 'Delete' })).toHaveLength(1));
+
+    expect(within(getRowByEmail(ownUser.email)).queryByRole('button', { name: 'Delete' })).toBeNull();
+    expect(within(getRowByEmail(user.email)).getByRole('button', { name: 'Delete' }).disabled).toBe(false);
+  });
+});

package/work-orders/UCM-AUTH-11.md

@@ -0,0 +1,185 @@
+# UCM-AUTH-11 — `UserListComponent` offers an admin the delete action on their own row
+
+# A. Envelope — authored by the Expertenchat
+
+## Goal & expected outcome
+
+- Goal: the user list never offers anyone the deletion of their own account.
+- Expected outcome:
+  - In `UserListComponent`, the row of the signed-in user renders **no** delete button — not a
+    disabled one, none at all. Every other row behaves exactly as today (enabled or disabled per
+    `canDeleteUser` / the default).
+  - This holds for every consumer, **including one that passes its own `canDeleteUser`**
+    (`AccountPage` forwards it as `userListCanDeleteUser`): a prop that returns true for the own row
+    does not bring the button back.
+  - Released; the Envelope's done-state is the release (consumer bumps are separate, see Risks).
+
+## Context — measured 2026-09-30 against `main` at 3.9.0
+
+- **Operator decision 2026-09-30 (from django-core-micha `DCM-AUTH-4`, dropped there): UI-only.**
+  The backend keeps allowing an admin's generic self-delete (`BaseUserViewSet.destroy()` refuses
+  only a non-admin's self-delete since dcm 2.44.1); the list simply stops offering it.
+- `src/components/UserListComponent.jsx`:
+  - `defaultCanEdit` (~l.128) returns true for `currentUser.is_superuser` and for role `admin` on
+    every row, the own row included (only the `teacher` branch excludes self).
+  - `canDelete` (~l.151) returns `canDeleteUser(...)` when that prop is a function, otherwise
+    `canEdit(targetUser)`.
+  - The delete button (~l.438-452) renders whenever `showDeleteAction` is true and is only
+    `disabled={!canDelete(row)}` — so a row that may not be deleted still shows a disabled button.
+- `src/pages/AccountPage.jsx` forwards `userListShowDeleteAction` (default true) and
+  `userListCanDeleteUser` (default null).
+- Consumers measured: kerzenziehen and reimbursements render `AccountPage` without these props, so
+  an admin there sees an enabled delete button on their own row today. jg-ferien passes its own
+  `userListCanDeleteUser`, which already returns false for the own row (the button shows disabled).
+
+## Scope + non-goals
+
+- In scope: the own-row rule in `UserListComponent` (identity by `id` of the row vs. the current
+  user), tests, CHANGELOG entry, release.
+- Explicit non-goals / do-not-touch:
+  - No backend change (dcm untouched).
+  - Rows other than the own row keep today's disabled-vs-enabled behaviour; no change to
+    `defaultCanEdit`.
+  - No other action on the own row changes (edit, extra row actions).
+  - Consumer pin bumps are not part of this WO.
+
+## Tier · gates
+
+- **Tier 3** — change inside shared-core, permission-adjacent UI.
+- Precondition: none.
+
+## Risks
+
+- **Reaching the two affected apps needs a major bump:** kerzenziehen and reimbursements pin
+  `@micha.bigler/ui-core-micha` **2.41.3**; 3.0.0 removed chart layout props (`UCM-CHART-12`). The
+  fix only reaches them with that bump, which is its own work per app and is classified there by
+  the dependency-bump rule.
+- The current user may be unknown while loading; with no current user the own-row rule must not
+  hide buttons on other rows or throw.
+- `id` types: compare the row id and the current user id so that `3` and `"3"` match.
+
+## Required tests to WRITE (you write them and run YOUR OWN new ones; the orchestrator's run is the gate)
+
+In `tests/UserListComponent.test.jsx`:
+
+1. Superuser, no `canDeleteUser`: own row has no delete button; another row has an enabled one.
+2. Role `admin`, no `canDeleteUser`: same as 1.
+3. `canDeleteUser` returning true for every row: own row still has no delete button.
+4. Current user not yet loaded: other rows unaffected, no error.
+5. **Mutation proof:** remove the own-row rule → tests 1 and 3 fail.
+
+---
+
+# B. Implementation map — filled by the Orchestrator — ADDRESSED TO THE IMPLEMENTER
+
+## Context package
+
+- File: `src/components/UserListComponent.jsx` (current state, verified against `main` at `3.9.0`
+  post-`UCM-AUTH-10`, line numbers below are exact).
+- **The fix must gate RENDERING, not just the disabled state.** `canDelete(row)` (line 151-156)
+  already decides enabled-vs-disabled; the delete `Button` (line 441-453) already renders
+  `disabled={!canDelete(row)}`. If the own-row rule were added INSIDE `canDelete`, the button would
+  still render, just permanently disabled — that is explicitly NOT what the Envelope asks for ("no
+  delete button — not a disabled one, none at all"). The rule must wrap the render, so a consumer's
+  `canDeleteUser` returning `true` for the own row cannot bring the button back (Required Test #3).
+- Add a small helper next to `canDelete` (around line 156):
+  ```js
+  const isOwnRow = (targetUser) => {
+    if (currentUser?.id == null || targetUser?.id == null) return false;
+    return String(targetUser.id) === String(currentUser.id);
+  };
+  ```
+  - `currentUser?.id == null` (loose check, catches both `undefined` and `null`) covers the "current
+    user not yet loaded" risk: when there is no current user at all, every row's `isOwnRow` is
+    `false`, so nothing is hidden and nothing throws (Required Test #4) — this function must NOT be
+    the place that decides "hide everything while loading"; it only ever answers "is THIS row me",
+    and answers `false` when that question is unanswerable.
+  - `String(...) === String(...)` is the fix for the Risk note's `id` type mismatch (`3` vs `"3"`).
+- Wire it into the existing render condition at line 438 — change
+  `{showDeleteAction && (` to `{showDeleteAction && !isOwnRow(row) && (` (the `Tooltip`/`Button`
+  JSX inside is otherwise byte-identical — do not touch its internals, only the gating condition
+  that decides whether that whole block renders at all).
+- Do not touch `canDelete`/`canEdit`/`defaultCanEdit` (line 128-156) — the non-goal is explicit that
+  every OTHER row's enabled-vs-disabled behaviour stays exactly as today; this fix only removes the
+  own row's button, it does not change what `canDelete` returns for anyone (a consumer's
+  `canDeleteUser({ targetUser, currentUser, extraContext })` for the own row may still return
+  `true` internally — that return value is simply never consulted for the own row anymore, because
+  the render is gated before `canDelete(row)` is ever reached for that row's button).
+
+## Test file — `tests/UserListComponent.test.jsx` (existing — read it first for the render harness,
+## the `react-i18next`/`i18n` mock shape `UCM-AUTH-10` already fixed there, and `authApi` mocking
+## convention already established; extend it, do not replace its structure)
+
+Five cases, matching the Required Tests 1-5 exactly:
+1. `currentUser = { id: 99, is_superuser: true, ... }`, `fetchUsersList` resolves a list including a
+   row with `id: 99` (the signed-in user) and at least one other row (e.g. `id: 1`); no
+   `canDeleteUser` prop passed. Assert: querying delete buttons by accessible name/role yields exactly
+   one (for the OTHER row), and it is not disabled; no delete button exists for the row whose `id`
+   is `99` (e.g. scope the query to that row's `TableRow` — check how existing tests in this file
+   locate a specific row, or use `within(row)` from `@testing-library/react` if not already
+   imported).
+2. Same shape, `currentUser.role = 'admin'` instead of `is_superuser` — same assertions.
+3. Pass `canDeleteUser={() => true}` (unconditionally true for every row, including the own one) —
+   assert the own row STILL has no delete button, while the other row's is enabled (proves the
+   render-level gate wins over a consumer prop, not just over the default `canEdit`-based logic).
+4. Render with `currentUser = null` (or omit the prop) while `fetchUsersList` resolves a list
+   including a row that happens to share no id with anyone — assert the component does not throw
+   (no unhandled rejection/render error) and renders without crashing; per the Envelope's own
+   framing, unauthenticated/loading state does not by itself grant any row a delete button (this
+   test is about NOT crashing and NOT hiding unrelated rows, not about granting new permissions —
+   keep whatever the existing default-canEdit-based enabled/disabled state would be for other rows
+   in this configuration, do not assert a specific enabled/disabled state you have not verified from
+   `defaultCanEdit`'s own logic for a null `currentUser`, which already returns `false` unconditionally
+   at line 129 — so with the default `canDeleteUser`, every row is disabled-but-present in this
+   configuration; assert exactly that: buttons present and disabled, none of them thrown away).
+5. **Mutation proof required by the Envelope itself:** after writing tests 1 and 3, temporarily
+   comment out or revert the `!isOwnRow(row)` addition in your own working copy, re-run tests 1 and
+   3 ONLY, confirm both fail, then restore the fix and confirm the full focused file is green again.
+   Narrate this in `PROGRESS` (which two tests failed, then the restore) rather than leaving a
+   permanently-broken toggle in the committed test file — same pattern already used successfully in
+   this repo's own `UCM-THEME-15`/`UCM-PRIM-2` work orders for an identical "prove it would fail"
+   requirement.
+
+## Do-not-touch / invariants
+
+- No backend change (dcm is a separate repo, untouched, and out of scope regardless).
+- No change to `defaultCanEdit`/`canEdit`/`canDelete`'s return values for any OTHER row.
+- No change to any other action on the own row (role select, extra row actions) — only the delete
+  button's presence.
+- No consumer (`AccountPage`, etc.) touched — this fix is entirely inside `UserListComponent.jsx`.
+
+## Target repo working directory (absolute)
+
+`C:\Users\biglmi\Documents\webapps\ui-core-micha` (branch `main`)
+
+## Preamble — a REQUIRED block IN this file, not something appended at invocation
+
+> The text above is the COMPLETE spec — the committed WO file's content, not a plan to refine; there
+> is no separate plan file. Read the nearest `AGENTS.md`, the relevant `.codex/skills/<role>/SKILL.md`, and the
+> app `MEMORY.md` ONLY for conventions. Stay in scope; do not touch auth/permissions/deps/schema/CI
+> unless the spec says so; do not update `MEMORY.md`. **Do NOT edit `WORK_ORDERS.md` — the register
+> row and the review verdicts are the orchestrator's alone.** **Your tools are for editing source
+> and test files and for running the tests you wrote — nothing else.** Do NOT install dependencies,
+> touch a lockfile, run a package manager, or tidy up stray files; if something in the repo state
+> blocks you, stop and report it as `RESULT: BLOCKED <reason>` instead of fixing it. Do NOT
+> `git add`/`commit`/`push` — leave every
+> change uncommitted in the working tree for the orchestrator's independent review. WRITE the tests
+> the `Required tests` section calls for AND **RUN the tests you just wrote** to confirm they execute
+> and pass — that is the ONLY test run you do (NOT the app's affected/full suite, NOT any review).
+> The orchestrator re-runs the authoritative set + does the independent review after you finish —
+> those are the gate; your own run does not count as the gate.
+>
+> Narrate continuously: a `PLAN: <step1> | <step2> | …` line up front, then a single-line
+> `PROGRESS: [<n>/<total>] <present-tense action>` before every relevant action (and `… done` on
+> completion), spaced so no gap exceeds ~2 min, stdout unbuffered, plus exactly one final
+> `RESULT: DONE|BLOCKED <reason>`.
+
+---
+
+# C. Orchestrator only — NOT ADDRESSED TO THE IMPLEMENTER
+
+> **If you are the implementer reading this work order as your own specification: STOP at this line.
+> Everything below describes what the Orchestrator does AFTER you finish. You do none of it — no
+> reviewers, no verification run, no register edit, no commit.**
+
+*(to be filled by the Orchestrator: execution directive; `reviewer` (all lenses) + `ui_reviewer` + `sec_reviewer`; release (patch: behaviour fix of an existing component); register row stays `released` until consumers bump; register the kerzenziehen and reimbursements bumps in their own registers; commit.)*