Keep cache policy config multivalued on the custom provider screen - #53125

Closes #52029

What this fixes

SettingsCache addresses its config entries with an array index (config.maxLifespan[0]). That only resolves as long as the form holds the raw ComponentRepresentation, which is the case on the LDAP and Kerberos screens — both load with form.reset(component).

The custom provider screen loads with convertToFormValues(), which deliberately unwraps single-valued config entries into plain strings, because that is what DynamicComponents expects for the provider's own properties. The index then resolved against a string and yielded its first character.

Registering a control on an index path writes the resolved value back into the form, so the truncation happens on render and does not need an edit to be persisted:

shared/Header.tsx saves from the enable/disable toggle without a dirty check, so toggling a custom provider off and on is enough to lose the configured value.

This is option A as agreed in the issue: the multivalued shape of the five config entries that SettingsCache renders is restored after conversion, so the custom provider screen ends up with the same form shape as the LDAP and Kerberos screens. The provider's own properties stay unwrapped, and the existing save path accepts arrays unchanged.

A note on placement

The issue phrased option A as normalizing inside CustomProviderSettings.tsx. The helper is in SettingsCache.tsx instead, called from the custom screen, for two reasons:

1. The key list mirrors the field names a few lines below it in the same file. Keeping both together means a cache field added later cannot be missed.
2. It lets the regression test cover the conversion without pulling in the surrounding screen (admin client, contexts, router), which would otherwise have required mocking — something the contribution guidelines rule out.

Behaviour is identical either way; happy to inline it if you would rather keep the diff to a single file.

Testing

SettingsCache.test.tsx covers both load paths — the custom provider screen's convertToFormValues + setupCacheForm, and the form.reset(component) the LDAP and Kerberos screens use. Five assertions on the resulting form values, plus six that render the real controls and check the displayed value, an untouched save and an edited save, which is what catches the write-back.

Verified that 4 of the 11 fail without the fix, including both custom provider render assertions (expected '5' to be '50'), while every LDAP and Kerberos case stays green. Full admin-ui suite: 76/76. eslint, prettier and tsc are clean for the touched files.

No Playwright test: the e2e job starts a plain kc.sh start-dev with no deployed providers, and the custom provider screen only exists for an actually deployed UserStorageProvider, so covering it there would mean shipping a provider JAR with the e2e setup. Worth noting that the existing Kerberos cache policy specs only assert the policy label, never the value, which is why this went unnoticed.

Left out on purpose

NumberControl does value + 1 on a string, so stepping a stored 50 with the + button yields 501 — on every screen, LDAP included. That is an independent, pre-existing defect in a shared control used in around 20 places, so it is tracked separately in #53126 rather than fixed here.

Credit

#52198 by @MahathirMohammadShuvo addresses the same issue and he offered to defer this one. His analysis surfaced the render-time write-back and the missing dirty check in Header.tsx, both of which are reflected above, as well as the NumberControl defect. His variant makes SettingsCache itself shape-agnostic by deriving the field name from the shape present, which notably does not need the NumberControl special casing that option B was rejected for — worth a look if you would rather fix the shared component than the calling screen.

Generative AI disclosure

Claude Code was used to investigate the root cause and to draft the fix, the tests and this description. All changes were reviewed by me before submitting.