Keycloak admin: "create disabled user" confirmation dialog renders COMPLETELY EMPTY and cannot be closed (missing TranslocoDirective import) #903

New Issue

2026-07-30T07:28:09Z

spikerj commented

2026-07-30 07:28:09 +00:00

Found while adding render coverage for the user-create wizard (wave-5 coverage loop, angular branch test/component-coverage-wave5).

Severity

Hard dead-end. The dialog renders with no text and no buttons, and it is opened with disableClose: true — so there is no confirm, no cancel, no backdrop click and no ESC. The admin must reload the page, losing the entire half-completed create-user wizard.

Reproduce

Keycloak admin → Users → Create user
On step 1, untick Enabled
Click Next

A modal opens. It is blank. Nothing can be clicked. The page must be reloaded.

Root cause

DisabledUserConfirmationDialog (libraries/keycloak-admin/src/lib/components/user-create/user-create.component.ts:321) declares:

@Component({
  selector: "app-disabled-user-confirmation-dialog",
  imports: [MatDialogModule, MatButtonModule, MatIconModule],   // <-- no TranslocoDirective
  templateUrl: "./user-create-confirm-dialog.component.html",
  changeDetection: ChangeDetectionStrategy.OnPush,
  styleUrl: "./user-create-confirm-dialog.component.scss",
})
export class DisabledUserConfirmationDialog { ... }

but its template wraps everything in the transloco structural directive:

<ng-container *transloco="let t">
  <div class="dialog-content">
    ...heading, body copy, and BOTH buttons...
  </div>
</ng-container>

*transloco desugars to <ng-template [transloco]="…">. With TranslocoDirective absent from the standalone component's imports, no directive matches, so the template is never instantiated and the entire subtree — including the two buttons — is never created.

The parent UserCreateComponent in the same file does import TranslocoDirective; the dialog was evidently added later and did not.

Verified empirically: a direct TestBed.createComponent(DisabledUserConfirmationDialog) renders 0 buttons and empty text content. The dialog class's own onCancel() / onConfirm() methods are correct — they are simply unreachable.

Why it was invisible

The dialog is opened through MatDialog, so no existing spec ever rendered its template (the wizard spec mocks MatDialog).
Its template was 15/15 lines uncovered before this ticket.
The only entry point is the uncommon "create a disabled user" path.

Fix

Add the directive to the dialog's imports:

imports: [MatDialogModule, MatButtonModule, MatIconModule, TranslocoDirective],

Please also consider dropping disableClose: true at the call site (user-create.component.ts:255) or adding a close affordance, so that a future rendering failure degrades to a dismissible dialog rather than a locked page.

Tests

user-create-confirm-dialog.render.spec.ts (new) currently PINS the broken behaviour with a characterization test naming this ticket, alongside the assertions that should pass once fixed (two buttons, close(false) on cancel, close(true) only on explicit confirm). Flip the characterization test to the real assertions as part of the fix — they are already written and commented in that file.

Found while adding render coverage for the user-create wizard (wave-5 coverage loop, angular branch `test/component-coverage-wave5`). ## Severity **Hard dead-end.** The dialog renders with no text and **no buttons**, and it is opened with `disableClose: true` — so there is no confirm, no cancel, no backdrop click and no ESC. The admin must reload the page, losing the entire half-completed create-user wizard. ## Reproduce 1. **Keycloak admin → Users → Create user** 2. On step 1, untick **Enabled** 3. Click **Next** A modal opens. It is blank. Nothing can be clicked. The page must be reloaded. ## Root cause `DisabledUserConfirmationDialog` (`libraries/keycloak-admin/src/lib/components/user-create/user-create.component.ts:321`) declares: ```ts @Component({ selector: "app-disabled-user-confirmation-dialog", imports: [MatDialogModule, MatButtonModule, MatIconModule], // <-- no TranslocoDirective templateUrl: "./user-create-confirm-dialog.component.html", changeDetection: ChangeDetectionStrategy.OnPush, styleUrl: "./user-create-confirm-dialog.component.scss", }) export class DisabledUserConfirmationDialog { ... } ``` but its template wraps **everything** in the transloco structural directive: ```html <ng-container *transloco="let t"> <div class="dialog-content"> ...heading, body copy, and BOTH buttons... </div> </ng-container> ``` `*transloco` desugars to `<ng-template [transloco]="…">`. With `TranslocoDirective` absent from the standalone component's `imports`, no directive matches, so the template is never instantiated and the entire subtree — including the two buttons — is never created. The parent `UserCreateComponent` in the same file *does* import `TranslocoDirective`; the dialog was evidently added later and did not. Verified empirically: a direct `TestBed.createComponent(DisabledUserConfirmationDialog)` renders **0 buttons and empty text content**. The dialog class's own `onCancel()` / `onConfirm()` methods are correct — they are simply unreachable. ## Why it was invisible - The dialog is opened through `MatDialog`, so no existing spec ever rendered its template (the wizard spec mocks `MatDialog`). - Its template was **15/15 lines uncovered** before this ticket. - The only entry point is the uncommon "create a *disabled* user" path. ## Fix Add the directive to the dialog's imports: ```ts imports: [MatDialogModule, MatButtonModule, MatIconModule, TranslocoDirective], ``` Please also consider **dropping `disableClose: true`** at the call site (`user-create.component.ts:255`) or adding a close affordance, so that a future rendering failure degrades to a dismissible dialog rather than a locked page. ## Tests `user-create-confirm-dialog.render.spec.ts` (new) currently PINS the broken behaviour with a characterization test naming this ticket, alongside the assertions that should pass once fixed (two buttons, `close(false)` on cancel, `close(true)` only on explicit confirm). **Flip the characterization test to the real assertions as part of the fix** — they are already written and commented in that file.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#903