keycloak-admin user-roles: both role-search boxes are wired to nothing #762

New Issue

2026-07-21T03:00:08Z

spikerj commented

2026-07-21 03:00:08 +00:00

Found during #722 E5 R1 (PR spikersoft-angular#497): the realm-roles and client-roles search fields in user-roles.component were bound to FormControls whose values were never consumed by any filtering logic — typing in them has never done anything. The Signal Forms conversion preserved that behavior verbatim (now form(signal) fields with a code comment flagging the situation) rather than silently changing UX in a migration PR.

Decide: wire them up (filter availableRealmRoles() / availableClientRoles() computeds by the search signals — the models are already signals, so it's a two-line computed change each) or remove the two search fields. Wiring up is probably 15 minutes now that the plumbing is signals.

Found during #722 E5 R1 (PR spikersoft-angular#497): the realm-roles and client-roles search fields in `user-roles.component` were bound to FormControls whose values were **never consumed by any filtering logic** — typing in them has never done anything. The Signal Forms conversion preserved that behavior verbatim (now `form(signal)` fields with a code comment flagging the situation) rather than silently changing UX in a migration PR. Decide: wire them up (filter `availableRealmRoles()` / `availableClientRoles()` computeds by the search signals — the models are already signals, so it's a two-line `computed` change each) or remove the two search fields. Wiring up is probably 15 minutes now that the plumbing is signals.

spikerj commented

2026-07-22 02:49:42 +00:00

Board-sweep verification (2026-07-22): still live — no input/keyup/model binding found on either role-search box in keycloak-admin user-detail on current master; the search fields remain decorative. No fix commits reference keycloak-admin since filing.

spikerj commented

2026-07-29 15:44:35 +00:00

Re-verified against origin/master — still unwired. Both boxes render and neither filters anything.

Templates: libraries/keycloak-admin/src/lib/components/user-roles/user-roles.component.html:93-101 (realm roles) and :325-333 (client roles) — both real matInput fields with labels and a search icon, so they look functional.

Component: user-roles.component.ts:87-90 holds realmSearch / clientSearch signals with matching form() field trees — but nothing downstream reads them. availableRealmRoles() (:200) and availableClientRoles() (:225) filter only by selected id, never by the search term.

One thing worth recording: this file was migrated to Signal Forms by the E5 wave (epic #722), and that pass deliberately preserved the bug. The code says so at :84-86:

// Search + client-selection models (Signal Forms). The two search fields are
// display-only today (no filtering consumer) — preserved as-is from the

So this isn't an oversight waiting to be noticed — it's a known no-op that survived a refactor of the exact lines involved. The fix is small: derive the displayed role lists through a computed that filters on the search signal (case-insensitive includes on role name), for both realm and client lists.

Notes were accurate; no work has landed.

Re-verified against `origin/master` — **still unwired.** Both boxes render and neither filters anything. Templates: `libraries/keycloak-admin/src/lib/components/user-roles/user-roles.component.html:93-101` (realm roles) and `:325-333` (client roles) — both real `matInput` fields with labels and a search icon, so they look functional. Component: `user-roles.component.ts:87-90` holds `realmSearch` / `clientSearch` signals with matching `form()` field trees — but nothing downstream reads them. `availableRealmRoles()` (`:200`) and `availableClientRoles()` (`:225`) filter only by selected id, never by the search term. One thing worth recording: this file was migrated to Signal Forms by the E5 wave (epic #722), and that pass **deliberately preserved the bug**. The code says so at `:84-86`: > `// Search + client-selection models (Signal Forms). The two search fields are` > `// display-only today (no filtering consumer) — preserved as-is from the` So this isn't an oversight waiting to be noticed — it's a known no-op that survived a refactor of the exact lines involved. The fix is small: derive the displayed role lists through a `computed` that filters on the search signal (case-insensitive `includes` on role name), for both realm and client lists. Notes were accurate; no work has landed.

spikerj referenced this issue

2026-07-29 15:52:08 +00:00

Flaky under load: keycloak-admin user-list spec settles resources with a fixed hop count (reddens full-suite SonarQube scan); 9 sibling specs share the pattern #830

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#762