## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

…-2025.10) (#18044)

website/release notes: fix broken urls (#18041)

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

Co-authored-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* admin: make empty table message configurable

# What

This commit provides a new field at the Table level for the empty state message. The field defaults to the original message, “No objects found.”

# Why

The icon has long been configurable, but not the message. It makes sense to customize this message and let people know if they’re looking at files, properties, applications, and other objects.

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web: lint pass to add all missing custom component imports

# What

The latest version of lit-analyze found 53(!) places in the codebase where we referenced a custom web component but not guarantee that it had been registered with the browser. Most of these are so commonplace that they had already been pulled in and registered elsewhere, but it’s still bad practice to leave these out.

* web/maintenance: lint pass to fix broken or unrecognized tag names

# What

This code removes two places in the code that referenced obsolete tag names.

In AkWizardFormPage, the case was a tag that was defined but never used. It, in turn, referenced a tag that did not exist.

In AkApplicationWizard’s ProviderChoices, we referenced eight custom components that did not exist and were never defined anywhere in the code. The references to `renderers` were obsolete; despite being defined they were never used. (This lack of use was covered up by lots of `export`s discarding Typescript’s check against unused field.)

- [x] The code has been formatted

# Why

- WizardFormPage references ‘ak-wizard-form’, which does not exist
- No other component imports, inherits, or extends WizardFormPage. It only exists by itself.

``` shell
$ rg 'WizardFormPage'
src/elements/wizard/WizardFormPage.ts
39:export class WizardFormPage extends WizardPage {
```

- The objects referenced here in these renderers do not exist.
- Without them, the priority ordering code becomes much simpler
- No LocalTypeCreate calls are needed; just use the default API TypeCreate types now

<!-- -->

    ./src/admin/applications/wizard/steps/ProviderChoices.ts

        Unknown tag <ak-application-wizard-authentication-by-oauth>. Did you mean <ak-application-wizard-application-step>?
        19:  html`<ak-application-wizard-authentication-by-oauth></ak-appl
        no-unknown-tag-name

        Unknown tag <ak-application-wizard-authentication-by-saml-configuration>. Did you mean <ak-application-wizard-application-step>?
        24:  html`<ak-application-wizard-authentication-by-saml-configuration></ak-appl
        no-unknown-tag-name

* Revert "web/maintenance: lint pass to fix broken or unrecognized tag names"

This reverts commit e9e073f.

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/maintenance: lint pass to fix broken or unrecognized tag names

# What

This code removes two places in the code that referenced obsolete tag names.

In AkWizardFormPage, the case was a tag that was defined but never used. It, in turn, referenced a tag that did not exist.

In AkApplicationWizard’s ProviderChoices, we referenced eight custom components that did not exist and were never defined anywhere in the code. The references to `renderers` were obsolete; despite being defined they were never used. (This lack of use was covered up by lots of `export`s discarding Typescript’s check against unused field.)

- [x] The code has been formatted

# Why

- WizardFormPage references ‘ak-wizard-form’, which does not exist
- No other component imports, inherits, or extends WizardFormPage. It only exists by itself.

``` shell
$ rg 'WizardFormPage'
src/elements/wizard/WizardFormPage.ts
39:export class WizardFormPage extends WizardPage {
```

- The objects referenced here in these renderers do not exist.
- Without them, the priority ordering code becomes much simpler
- No LocalTypeCreate calls are needed; just use the default API TypeCreate types now

<!-- -->

    ./src/admin/applications/wizard/steps/ProviderChoices.ts

        Unknown tag <ak-application-wizard-authentication-by-oauth>. Did you mean <ak-application-wizard-application-step>?
        19:  html`<ak-application-wizard-authentication-by-oauth></ak-appl
        no-unknown-tag-name

        Unknown tag <ak-application-wizard-authentication-by-saml-configuration>. Did you mean <ak-application-wizard-application-step>?
        24:  html`<ak-application-wizard-authentication-by-saml-configuration></ak-appl
        no-unknown-tag-name

* A better way to prioritise, without losing the original script.

* further streamlining the priority order.

* Making it harder to add bad provider models to the application wizard.

* Prettier has opinions.

* Adding these to the tagname maps so lit-analyze can validate their uses.

* Made testing for valid returns from the server generic.  Suggestion from @GirlBossRush

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/maintenance/no-unknown-attributes-1

# What

This commit is a collection of fixes and adaptations discovered while running lit-analyzer in a stricter role than usual. These fixes are to 9 of the existing issues; there are 16 more that will be addressed in the next two pull requests.

The following issues were uncovered.

- `ak-slug-input` does not take `autocomplete`.
- `ak-wizard-page-type-create` does not take, or use, the `name` attribute. It also has no `value` of its own, so it is not processed as a form object.
- `ak-endpoints-device-access-groups-form` does not take a `pk` attribute. It takes an `.instancePk` property.
- `ak-provider-oauth2-redirect-uri` is only used in one place, and that place uses the term `input-id` for the key. The component was expected `inputId`. Since it is a string and therefore an attribute, kebab-case is the appropriate fix here.
- `input-mode` is not a valid attribute. The attribute is `inputmode`, and the property is `inputMode`. It may not be undefined. If it is defined, the default is `text`. I have fixed this in the attribute and in the two Forms that used it.
- `form-associated-element` had both `name` and `type` as readonly. Since they are native attributes, they can be attributes or they can be readonly. They can’t be both. I have made them read-write.
- `user-source-settings-page` is only used in one place, and that place uses the term `input-id` for the key. The component was expected `inputId`. Since it is a string and therefore an attribute, kebab-case is the appropriate fix here.

These guideposts will be placed on the PR.

* Update web/src/admin/providers/oauth2/OAuth2ProviderRedirectURI.ts

Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
Signed-off-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>

* Update web/src/components/ak-text-input.ts

Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
Signed-off-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>

* Fix duplicate lines in property declaration. Not sure how that snuck in there.

* Prettier has opinions.

---------

Signed-off-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>
Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/maintenance: lint pass to add missing HTMLElementTagNameMap entries

# What

This code mechanically adds HTMLElementTagNameMap entries to those files that were missing it.

Every entry in the report is in this format:

    ./src/elements/ak-table/stories/ak-select-table.stories.ts

        'ak-select-table-test-sort' has not been registered on HTMLElementTagNameMap
        84:  export class SimpleTableSortTest extends LitElem
        no-missing-element-type-definition

It was trivial to create a Perl script that extracted the file name, the tag name, and the class name, and turn that into a “Open this file and append the HTMLElementTagNameMap definition to the end,” then run `prettier` and `build` to validate that nothing broke.

I also had to hand-edit the JSDoc for `Form`. It is not, by itself, an element. It is an abstract class from which you can derive elements. The `@element` tag there confused lit-analyze, and lit-analyze was correct to call it out.

# Why

These entries help Typescript & Lit-Analyze lint our product, validating that each element is being used correctly and that the types being passed to it are correct.

…#18953)

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/maintenance: lint pass to add missing HTMLElementEventMap entries

# What

For events where we had, through whatever mechanisms we used, abstracted event names enough that Typescript struggled with them, those names have been added to the respective elements’ JSDoc entry, so that Lit-Analyze could look a little harder.

In several places, outdated test harnesses were using old event names.

Finally, for RapiDoc and Openlayers, the event names provided did not have ElementEventMap entries. Since those events will always be listened for, from the contents within the shadowDOM, the Lit guidelines recommend listening for those on a customElement attached to `this`, and built with the constructor. This is no hardship; the listener always travels with the `:host`, so it does not need to be attached or detached, and the event handing logic is unchanged.

However, that change led to *Typescript* now complaining that there was no HTMLElementEventMap entry for those specific events. I have added `ts-expect-error` pragmas in those two places, with the appropriate comment. This seems like the better compromise, as Typescript is more robust.

* Update web/src/admin/events/EventMap.ts

Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
Signed-off-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>

* Update web/src/standalone/api-browser/index.entrypoint.ts

Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
Signed-off-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>

* Github's merge mangled this badly.  Had to fix.

---------

Signed-off-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>
Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>

…tion (#19341)

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/admin: always retrieve selected provider when editing the application

# What

Re-writes the `fetch` function for ak-provider-search-input so that, if there’s an assigned value and it does not appear in the currently retrieved list of providers, prepend it to the list so that it is always present and always selectable.

# Why

Our pagination windows can restrict the list of objects retrieved from the server, and when we’re chasing composite objects we have to retrieve the displayable elements of that object from their respective tables. This combination means that a paginated retrieval may not have the object indicated by the parent object’s PK for that object collection. We have to retrieve it separately if it’s not in the current collection.

This problem is probably endemic to some of our design decisions.

…tion (#19341)

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/admin: always retrieve selected provider when editing the application

# What

Re-writes the `fetch` function for ak-provider-search-input so that, if there’s an assigned value and it does not appear in the currently retrieved list of providers, prepend it to the list so that it is always present and always selectable.

# Why

Our pagination windows can restrict the list of objects retrieved from the server, and when we’re chasing composite objects we have to retrieve the displayable elements of that object from their respective tables. This combination means that a paginated retrieval may not have the object indicated by the parent object’s PK for that object collection. We have to retrieve it separately if it’s not in the current collection.

This problem is probably endemic to some of our design decisions.

…tion (cherry-pick #19341 to version-2025.12) (#19370)

web/admin: always retrieve selected provider when editing the application (#19341)

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/admin: always retrieve selected provider when editing the application

# What

Re-writes the `fetch` function for ak-provider-search-input so that, if there’s an assigned value and it does not appear in the currently retrieved list of providers, prepend it to the list so that it is always present and always selectable.

# Why

Our pagination windows can restrict the list of objects retrieved from the server, and when we’re chasing composite objects we have to retrieve the displayable elements of that object from their respective tables. This combination means that a paginated retrieval may not have the object indicated by the parent object’s PK for that object collection. We have to retrieve it separately if it’s not in the current collection.

This problem is probably endemic to some of our design decisions.

Co-authored-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/bug/hidden-secrets-not-propagating

# What

This commit updates ak-secret-text-input, adding the `name` attribute to all valid input fields and updating the value writer to match those of known-working components, to ensure that either variety of the display is fully and correctly updated with the content of the hidden secret.

# Why

The hidden input field is the one that HorizontalFormElement was expecting to read its value from, but that field never received a `name` because it wasn’t present when the field was first updated.

HorizontalFormElement writes the `name` field to the first `<input>` it finds. That was the “dummy” input field, which has no working value.

Form ignored the input element because the value it read came with an undefined name.

Object-oriented state management sometimes bites.

---------

Co-authored-by: Jens Langhammer <jens@goauthentik.io>

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/bug/hidden-secrets-not-propagating

# What

This commit updates ak-secret-text-input, adding the `name` attribute to all valid input fields and updating the value writer to match those of known-working components, to ensure that either variety of the display is fully and correctly updated with the content of the hidden secret.

# Why

The hidden input field is the one that HorizontalFormElement was expecting to read its value from, but that field never received a `name` because it wasn’t present when the field was first updated.

HorizontalFormElement writes the `name` field to the first `<input>` it finds. That was the “dummy” input field, which has no working value.

Form ignored the input element because the value it read came with an undefined name.

Object-oriented state management sometimes bites.

---------

Co-authored-by: Jens Langhammer <jens@goauthentik.io>

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/bug/hidden-secrets-not-propagating

# What

This commit updates ak-secret-text-input, adding the `name` attribute to all valid input fields and updating the value writer to match those of known-working components, to ensure that either variety of the display is fully and correctly updated with the content of the hidden secret.

# Why

The hidden input field is the one that HorizontalFormElement was expecting to read its value from, but that field never received a `name` because it wasn’t present when the field was first updated.

HorizontalFormElement writes the `name` field to the first `<input>` it finds. That was the “dummy” input field, which has no working value.

Form ignored the input element because the value it read came with an undefined name.

Object-oriented state management sometimes bites.

---------

Co-authored-by: Jens Langhammer <jens@goauthentik.io>

…ersion-2025.10) (#19376)

web/elements: hidden secrets not propagating (#19029)

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/bug/hidden-secrets-not-propagating

# What

This commit updates ak-secret-text-input, adding the `name` attribute to all valid input fields and updating the value writer to match those of known-working components, to ensure that either variety of the display is fully and correctly updated with the content of the hidden secret.

# Why

The hidden input field is the one that HorizontalFormElement was expecting to read its value from, but that field never received a `name` because it wasn’t present when the field was first updated.

HorizontalFormElement writes the `name` field to the first `<input>` it finds. That was the “dummy” input field, which has no working value.

Form ignored the input element because the value it read came with an undefined name.

Object-oriented state management sometimes bites.

---------

Co-authored-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>

…ersion-2025.12) (#19377)

web/elements: hidden secrets not propagating (#19029)

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/bug/hidden-secrets-not-propagating

# What

This commit updates ak-secret-text-input, adding the `name` attribute to all valid input fields and updating the value writer to match those of known-working components, to ensure that either variety of the display is fully and correctly updated with the content of the hidden secret.

# Why

The hidden input field is the one that HorizontalFormElement was expecting to read its value from, but that field never received a `name` because it wasn’t present when the field was first updated.

HorizontalFormElement writes the `name` field to the first `<input>` it finds. That was the “dummy” input field, which has no working value.

Form ignored the input element because the value it read came with an undefined name.

Object-oriented state management sometimes bites.

---------

Co-authored-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web: fix early theme identification

# What

Upon initial load of the HTML, even before the Javascript VM has started loading the admin interface, check if the user has a theme name in localstorage and validate it before proceeding.

# Issue

[Leftover localStorage.theme breaks UI after update to 2025.12.0](#19387)

Reported: 2025-01-13 By: Github user @WIPocket

# Why

We’ve changed our theme names to the more customary “light” and “dark”; older installs may have our earlier keys, “light-theme” or “dark-theme”, and those can break the read, resulting in the theme not being loaded at all.

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web: fix early theme identification

# What

Upon initial load of the HTML, even before the Javascript VM has started loading the admin interface, check if the user has a theme name in localstorage and validate it before proceeding.

# Issue

[Leftover localStorage.theme breaks UI after update to 2025.12.0](#19387)

Reported: 2025-01-13 By: Github user @WIPocket

# Why

We’ve changed our theme names to the more customary “light” and “dark”; older installs may have our earlier keys, “light-theme” or “dark-theme”, and those can break the read, resulting in the theme not being loaded at all.

…to version-2025.12) (#19433)

web/startup: deprecated theme names break theming (#19431)

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web: fix early theme identification

# What

Upon initial load of the HTML, even before the Javascript VM has started loading the admin interface, check if the user has a theme name in localstorage and validate it before proceeding.

# Issue

[Leftover localStorage.theme breaks UI after update to 2025.12.0](#19387)

Reported: 2025-01-13 By: Github user @WIPocket

# Why

We’ve changed our theme names to the more customary “light” and “dark”; older installs may have our earlier keys, “light-theme” or “dark-theme”, and those can break the read, resulting in the theme not being loaded at all.

Co-authored-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web: lint pass to add all missing custom component imports

# What

The latest version of lit-analyze found 53(!) places in the codebase where we referenced a custom web component but not guarantee that it had been registered with the browser. Most of these are so commonplace that they had already been pulled in and registered elsewhere, but it’s still bad practice to leave these out.

* web/maintenance: lint pass to fix broken or unrecognized tag names

# What

This code removes two places in the code that referenced obsolete tag names.

In AkWizardFormPage, the case was a tag that was defined but never used. It, in turn, referenced a tag that did not exist.

In AkApplicationWizard’s ProviderChoices, we referenced eight custom components that did not exist and were never defined anywhere in the code. The references to `renderers` were obsolete; despite being defined they were never used. (This lack of use was covered up by lots of `export`s discarding Typescript’s check against unused field.)

- [x] The code has been formatted

# Why

- WizardFormPage references ‘ak-wizard-form’, which does not exist
- No other component imports, inherits, or extends WizardFormPage. It only exists by itself.

``` shell
$ rg 'WizardFormPage'
src/elements/wizard/WizardFormPage.ts
39:export class WizardFormPage extends WizardPage {
```

- The objects referenced here in these renderers do not exist.
- Without them, the priority ordering code becomes much simpler
- No LocalTypeCreate calls are needed; just use the default API TypeCreate types now

<!-- -->

    ./src/admin/applications/wizard/steps/ProviderChoices.ts

        Unknown tag <ak-application-wizard-authentication-by-oauth>. Did you mean <ak-application-wizard-application-step>?
        19:  html`<ak-application-wizard-authentication-by-oauth></ak-appl
        no-unknown-tag-name

        Unknown tag <ak-application-wizard-authentication-by-saml-configuration>. Did you mean <ak-application-wizard-application-step>?
        24:  html`<ak-application-wizard-authentication-by-saml-configuration></ak-appl
        no-unknown-tag-name

* Revert "web/maintenance: lint pass to fix broken or unrecognized tag names"

This reverts commit e9e073f.

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/maintenance: lint pass to add missing HTMLElementTagNameMap entries

# What

This code mechanically adds HTMLElementTagNameMap entries to those files that were missing it.

Every entry in the report is in this format:

    ./src/elements/ak-table/stories/ak-select-table.stories.ts

        'ak-select-table-test-sort' has not been registered on HTMLElementTagNameMap
        84:  export class SimpleTableSortTest extends LitElem
        no-missing-element-type-definition

It was trivial to create a Perl script that extracted the file name, the tag name, and the class name, and turn that into a “Open this file and append the HTMLElementTagNameMap definition to the end,” then run `prettier` and `build` to validate that nothing broke.

I also had to hand-edit the JSDoc for `Form`. It is not, by itself, an element. It is an abstract class from which you can derive elements. The `@element` tag there confused lit-analyze, and lit-analyze was correct to call it out.

# Why

These entries help Typescript & Lit-Analyze lint our product, validating that each element is being used correctly and that the types being passed to it are correct.

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/maintenance: lint pass to add missing HTMLElementTagNameMap entries

# What

This code mechanically adds HTMLElementTagNameMap entries to those files that were missing it.

Every entry in the report is in this format:

    ./src/elements/ak-table/stories/ak-select-table.stories.ts

        'ak-select-table-test-sort' has not been registered on HTMLElementTagNameMap
        84:  export class SimpleTableSortTest extends LitElem
        no-missing-element-type-definition

It was trivial to create a Perl script that extracted the file name, the tag name, and the class name, and turn that into a “Open this file and append the HTMLElementTagNameMap definition to the end,” then run `prettier` and `build` to validate that nothing broke.

I also had to hand-edit the JSDoc for `Form`. It is not, by itself, an element. It is an abstract class from which you can derive elements. The `@element` tag there confused lit-analyze, and lit-analyze was correct to call it out.

# Why

These entries help Typescript & Lit-Analyze lint our product, validating that each element is being used correctly and that the types being passed to it are correct.

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web: lint pass to add all missing custom component imports

# What

The latest version of lit-analyze found 53(!) places in the codebase where we referenced a custom web component but not guarantee that it had been registered with the browser. Most of these are so commonplace that they had already been pulled in and registered elsewhere, but it’s still bad practice to leave these out.

* web/maintenance: lint pass to fix broken or unrecognized tag names

# What

This code removes two places in the code that referenced obsolete tag names.

In AkWizardFormPage, the case was a tag that was defined but never used. It, in turn, referenced a tag that did not exist.

In AkApplicationWizard’s ProviderChoices, we referenced eight custom components that did not exist and were never defined anywhere in the code. The references to `renderers` were obsolete; despite being defined they were never used. (This lack of use was covered up by lots of `export`s discarding Typescript’s check against unused field.)

- [x] The code has been formatted

# Why

- WizardFormPage references ‘ak-wizard-form’, which does not exist
- No other component imports, inherits, or extends WizardFormPage. It only exists by itself.

``` shell
$ rg 'WizardFormPage'
src/elements/wizard/WizardFormPage.ts
39:export class WizardFormPage extends WizardPage {
```

- The objects referenced here in these renderers do not exist.
- Without them, the priority ordering code becomes much simpler
- No LocalTypeCreate calls are needed; just use the default API TypeCreate types now

<!-- -->

    ./src/admin/applications/wizard/steps/ProviderChoices.ts

        Unknown tag <ak-application-wizard-authentication-by-oauth>. Did you mean <ak-application-wizard-application-step>?
        19:  html`<ak-application-wizard-authentication-by-oauth></ak-appl
        no-unknown-tag-name

        Unknown tag <ak-application-wizard-authentication-by-saml-configuration>. Did you mean <ak-application-wizard-application-step>?
        24:  html`<ak-application-wizard-authentication-by-saml-configuration></ak-appl
        no-unknown-tag-name

* Revert "web/maintenance: lint pass to fix broken or unrecognized tag names"

This reverts commit e9e073f.

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/maintenance: lint pass to add missing HTMLElementTagNameMap entries

# What

This code mechanically adds HTMLElementTagNameMap entries to those files that were missing it.

Every entry in the report is in this format:

    ./src/elements/ak-table/stories/ak-select-table.stories.ts

        'ak-select-table-test-sort' has not been registered on HTMLElementTagNameMap
        84:  export class SimpleTableSortTest extends LitElem
        no-missing-element-type-definition

It was trivial to create a Perl script that extracted the file name, the tag name, and the class name, and turn that into a “Open this file and append the HTMLElementTagNameMap definition to the end,” then run `prettier` and `build` to validate that nothing broke.

I also had to hand-edit the JSDoc for `Form`. It is not, by itself, an element. It is an abstract class from which you can derive elements. The `@element` tag there confused lit-analyze, and lit-analyze was correct to call it out.

# Why

These entries help Typescript & Lit-Analyze lint our product, validating that each element is being used correctly and that the types being passed to it are correct.

…#18942 to version-2025.12) (#19636)

web/maintenance: fix missing custom web component imports (#18942)

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web: lint pass to add all missing custom component imports

# What

The latest version of lit-analyze found 53(!) places in the codebase where we referenced a custom web component but not guarantee that it had been registered with the browser. Most of these are so commonplace that they had already been pulled in and registered elsewhere, but it’s still bad practice to leave these out.

* web/maintenance: lint pass to fix broken or unrecognized tag names

# What

This code removes two places in the code that referenced obsolete tag names.

In AkWizardFormPage, the case was a tag that was defined but never used. It, in turn, referenced a tag that did not exist.

In AkApplicationWizard’s ProviderChoices, we referenced eight custom components that did not exist and were never defined anywhere in the code. The references to `renderers` were obsolete; despite being defined they were never used. (This lack of use was covered up by lots of `export`s discarding Typescript’s check against unused field.)

- [x] The code has been formatted

# Why

- WizardFormPage references ‘ak-wizard-form’, which does not exist
- No other component imports, inherits, or extends WizardFormPage. It only exists by itself.

``` shell
$ rg 'WizardFormPage'
src/elements/wizard/WizardFormPage.ts
39:export class WizardFormPage extends WizardPage {
```

- The objects referenced here in these renderers do not exist.
- Without them, the priority ordering code becomes much simpler
- No LocalTypeCreate calls are needed; just use the default API TypeCreate types now

<!-- -->

    ./src/admin/applications/wizard/steps/ProviderChoices.ts

        Unknown tag <ak-application-wizard-authentication-by-oauth>. Did you mean <ak-application-wizard-application-step>?
        19:  html`<ak-application-wizard-authentication-by-oauth></ak-appl
        no-unknown-tag-name

        Unknown tag <ak-application-wizard-authentication-by-saml-configuration>. Did you mean <ak-application-wizard-application-step>?
        24:  html`<ak-application-wizard-authentication-by-saml-configuration></ak-appl
        no-unknown-tag-name

* Revert "web/maintenance: lint pass to fix broken or unrecognized tag names"

This reverts commit e9e073f.

Co-authored-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web: Remove PFBase.

* Remove stub.

* Just keeping this around.

* web/maintenance: deprecate PFBase in favor of an adopted stylesheet

# What !?!?!?

Removes `PFBase` from all components.

# Why !?!?!?

In `AkElement`, there was this code:

        protected static override finalizeStyles(styles?: CSSResultGroup): CSSResultOrNative[] {
            if (!styles) return [$PFBase, $AKBase];

            if (!Array.isArray(styles)) return [$PFBase, createCSSResult(styles), $PFBase, $AKBase];

            return [
                $PFBase,
                // ---
                ...(styles.flat() as CSSResultOrNative[]).map(createCSSResult),
                $AKBase,
            ];
        }

I’ve refined this:

        protected static override finalizeStyles(styles: CSSResultGroup = []): CSSResultOrNative[] {
            const elementStyles = [
                $PFBase,
                // Route around TSC`s known-to-fail typechecking of `.flat(Infinity)`. Removes types.
                ...([styles] as Array<unknown>).flat(Infinity),
                $AKBase,
                // Restore types. Safe: we control AKBase and PFBase in this file, and `styles` are
                // typed on function signature.
            ] as CSSResultOrNative[];

            // Remove duplicates in reverse order to preserve last-insert-wins semantics of CSS.
            const elementSet = new Set(elementStyles.reverse());
            // Reverse again because the return type is an array, and process as a CSSResult
            return Array.from(elementSet).reverse().map(createCSSResult);
        }

… with the duplication removal documented in Lit 3.0. `styles` defaults to an array, is cast to an array, then automatically flattented before the deduplication is run.

With this, both PFBase and AKBase are automatically included with each and every component that inherits from `AKElement`. At that point, the inclusion of `PFBase` interface-wide made no sense.

So they had to be removed:

    $ for i in $(rg -t typescript -l PFBase | rg -v 'elements/Base\.ts') ; do \
        perl -pi.bak -e 's{import PFBase from ".patternfly/patternfly/patternfly-base.css";}{}' "$i" ; \
        done
    $ for i in $(rg -t typescript -l PFBase | rg -v 'elements/Base\.ts') ; do \
        perl -pi.bak -e 's/PFBase,//' "$i" ; \
        done

This commit removes 131 `import` statements from the source code. As a result, the bundle is about 27K smaller… which admittedly is about 0.2% smaller than before. Ah, well. “Every little bit helps,” right?

* Update comment to point to semantic rules for `finalizeStyles` in Lit reactive-element

* Yeah, didn't need the analysis files lying around.

* Merge confirmed

---------

Co-authored-by: Teffen Ellis <teffen@goauthentik.io>

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/maintenance: lint pass to add missing HTMLElementTagNameMap entries

# What

This code mechanically adds HTMLElementTagNameMap entries to those files that were missing it.

Every entry in the report is in this format:

    ./src/elements/ak-table/stories/ak-select-table.stories.ts

        'ak-select-table-test-sort' has not been registered on HTMLElementTagNameMap
        84:  export class SimpleTableSortTest extends LitElem
        no-missing-element-type-definition

It was trivial to create a Perl script that extracted the file name, the tag name, and the class name, and turn that into a “Open this file and append the HTMLElementTagNameMap definition to the end,” then run `prettier` and `build` to validate that nothing broke.

I also had to hand-edit the JSDoc for `Form`. It is not, by itself, an element. It is an abstract class from which you can derive elements. The `@element` tag there confused lit-analyze, and lit-analyze was correct to call it out.

# Why

These entries help Typescript & Lit-Analyze lint our product, validating that each element is being used correctly and that the types being passed to it are correct.

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/maintenance: lint pass to add missing HTMLElementTagNameMap entries

# What

This code mechanically adds HTMLElementTagNameMap entries to those files that were missing it.

Every entry in the report is in this format:

    ./src/elements/ak-table/stories/ak-select-table.stories.ts

        'ak-select-table-test-sort' has not been registered on HTMLElementTagNameMap
        84:  export class SimpleTableSortTest extends LitElem
        no-missing-element-type-definition

It was trivial to create a Perl script that extracted the file name, the tag name, and the class name, and turn that into a “Open this file and append the HTMLElementTagNameMap definition to the end,” then run `prettier` and `build` to validate that nothing broke.

I also had to hand-edit the JSDoc for `Form`. It is not, by itself, an element. It is an abstract class from which you can derive elements. The `@element` tag there confused lit-analyze, and lit-analyze was correct to call it out.

# Why

These entries help Typescript & Lit-Analyze lint our product, validating that each element is being used correctly and that the types being passed to it are correct.

 to version-2025.12) (#19638)

web/maintenance: no missing element type definitions (#18950)

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/maintenance: lint pass to add missing HTMLElementTagNameMap entries

# What

This code mechanically adds HTMLElementTagNameMap entries to those files that were missing it.

Every entry in the report is in this format:

    ./src/elements/ak-table/stories/ak-select-table.stories.ts

        'ak-select-table-test-sort' has not been registered on HTMLElementTagNameMap
        84:  export class SimpleTableSortTest extends LitElem
        no-missing-element-type-definition

It was trivial to create a Perl script that extracted the file name, the tag name, and the class name, and turn that into a “Open this file and append the HTMLElementTagNameMap definition to the end,” then run `prettier` and `build` to validate that nothing broke.

I also had to hand-edit the JSDoc for `Form`. It is not, by itself, an element. It is an abstract class from which you can derive elements. The `@element` tag there confused lit-analyze, and lit-analyze was correct to call it out.

# Why

These entries help Typescript & Lit-Analyze lint our product, validating that each element is being used correctly and that the types being passed to it are correct.

Co-authored-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/admin: source-forms-not-rendering

# What

Replaces the logic for determining types in the `StrictUnsafe` directive such that all types are assessed for `isProperty` first, and if it’s not a property, `String()` types are passed as an attribute, not a property. Just checking the type for `Boolean` is not sufficient.

Replaces the logic for rendering the SourceForms to ensure that forms that do not need a model name are not passed a model name. Run-time type-checking was failing for forms that do not take a model name because they already know it.

# Why

This looks like a case of excessive cleverness and insufficient testing. Trying to abstract the creation of the models down to a single call without breaking the code is an admirable goal, but this is fragile code because of the demands of the different models, especially the OAuth2 models which have different names depending on the uniqueness of the source (Discord vs Azure vs Mailcow, etc.).

# Incomplete

The code also suffers from a second level of cleverness in that it delays the render of the form until the modal is made visible. This works for the modal for creating new sources, and it seems to work fine on the “View One Source -\> \[Edit\]” case, but the edit button on the SourcesList page does not work.

* Makes edit button work on SourceListPage again.

* Provide proper text in the proper location to properly populate the 'Update' button text.

* Just bumping the number to restart testing.

)

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* Adding Object.assign polyfill to sfe to handling bundling issue.

…-to-maintain table (#19999)

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/flow: refactor FlowExecutor so that client-side stage selection is separate from stage execution

# What

Extracts and normalizes the *massive* switch/case statement into a table, eliminating as much repetition as possible. Where the server-side stage token and the client-side component have the same tag, only one is required. There were three different patterns for prop definitions, and those have been regularized into an expression with a compile-time type check, and the most common one can be omitted from the stage definition table.

# Why

1.  Because it’s hella cleaner. Stages are clear and easy to spot in the table (especially when it’s alphabetically ordered, OMG). Stages that disagree in name with their components, stages that take props different from the “standard” set, and stages that need `import` statements, are all easy to identify.
2.  Because identifying what we *do* with our web components is critical to their success, and to the success of the styling system the authentik web team envisions. FlowExecutor provides selection and execution of stages, but it also provides the inspector, the locale selector, headers, footers, customizations, and branding. Clearing away clutter to make that easier to see makes future refactoring for compatibility mode and dark theme handling much easier.

* web/flow: clean up state representation in FlowExecutor (#20027)

* web/flow: clean up state representation in FlowExecutor

# What

Cleans up the state and lifecycle of FlowExecutor.

*As state lifecycle*, the two fields `challenge` and `flowInfo` are synonymous: they are modified at the same time, once in the setter, and once in `updated()`; flowInfo is always a derived consequence of that current challenge. Making `challenge` the property that we are monitoring and `flowInfo` a simple accessor on `challenge` eliminates duplication of state management.

Lit automatically schedules a re-render whenever `challenge` is changed; the `requestUpdate()` is therefore not needed.

With that, the only thing left is where or when to change the document title. That too is moved to `updated()` and happens without checking for need; it does no harm to replace a string with its own value, the performance loss is so small as to be non-existent, it will not confuse the browser or the environment. Eliminating an `if` and reducing the code surface to a pattern check is a win.

FlowExecutor now has only three states: Loading, Challenge Available, and… Inspector? Let’s see what we can do about cleaning these up as well. Loading and Challenge do not seem synonymous: the challenge should not be altered until the fetch is complete, to prevent blank displays.

* web/flow: dedupe the set error flow state (#20029)

* web/flow: dedupe the set error flow state

# What

Extracts the logic for setting the flow state to FlowError.

# Why

It was just duplication. Trying to clean up state management is easier when special state handling is isolated into a single method.

* Protected.

---------

Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>

---------

Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>

* Fix types.

* web: Flesh out module driven tag names.

* web/flow: optimize table for type safety

# What

Separate out the “here’s how a stage is defined” from “Here’s how a stage is represented internally.” This gives us a nice central store of where to define how the server-side componentName relates to a client-side customElementName while also guaranteeing that the componenName or supplied customElementName exists and corresponds. Type safety has been preserved system-wide (thanks, @GirlBossRush!)

* Tidy.

* Removed the cache; it's extra code for no benefit whatsoever; the table is constructed ONCE at start-up, there's never going to be a cache hit.  The FlowExecutorStageFactory produces StageMappings (StageMapping[]), which is itself a warehouse of singular server-component -> client-component relationships, fetching the client from the bundle as needed.  The StageMapping only does the fetch once per instance, so (for example) a password failure will reinstantiate a PasswordStage, but it will not fetch it a second time.

* Removed comments about the cache.  Added comments about where to find the FlowExecutor stage table. Moved the import of WebAuthnAuthenticticatorRegisterState from FlowExecutor.ts to FlowExecutorStages.ts; both files are bundled together, so this is a no-op functionally, but it's easier to confirm that StageEntries without import expressions (STageModuleCallbacks) have their stages bundled (pre-imported) if the import statement is in the same file.

* web: Flesh out stage mapping error handling. (#20292)

Co-authored-by: Ken Sternberg <ken@goauthentik.io>

* Restore fallback to use token if neither tag nor import are present.

* Bad check.

---------

Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>

…se it for the lifetime of the FlowExecutor (#20030)

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/flow: refactor FlowExecutor so that client-side stage selection is separate from stage execution

# What

Extracts and normalizes the *massive* switch/case statement into a table, eliminating as much repetition as possible. Where the server-side stage token and the client-side component have the same tag, only one is required. There were three different patterns for prop definitions, and those have been regularized into an expression with a compile-time type check, and the most common one can be omitted from the stage definition table.

# Why

1.  Because it’s hella cleaner. Stages are clear and easy to spot in the table (especially when it’s alphabetically ordered, OMG). Stages that disagree in name with their components, stages that take props different from the “standard” set, and stages that need `import` statements, are all easy to identify.
2.  Because identifying what we *do* with our web components is critical to their success, and to the success of the styling system the authentik web team envisions. FlowExecutor provides selection and execution of stages, but it also provides the inspector, the locale selector, headers, footers, customizations, and branding. Clearing away clutter to make that easier to see makes future refactoring for compatibility mode and dark theme handling much easier.

* web/flow: clean up state representation in FlowExecutor

# What

Cleans up the state and lifecycle of FlowExecutor.

*As state lifecycle*, the two fields `challenge` and `flowInfo` are synonymous: they are modified at the same time, once in the setter, and once in `updated()`; flowInfo is always a derived consequence of that current challenge. Making `challenge` the property that we are monitoring and `flowInfo` a simple accessor on `challenge` eliminates duplication of state management.

Lit automatically schedules a re-render whenever `challenge` is changed; the `requestUpdate()` is therefore not needed.

With that, the only thing left is where or when to change the document title. That too is moved to `updated()` and happens without checking for need; it does no harm to replace a string with its own value, the performance loss is so small as to be non-existent, it will not confuse the browser or the environment. Eliminating an `if` and reducing the code surface to a pattern check is a win.

FlowExecutor now has only three states: Loading, Challenge Available, and… Inspector? Let’s see what we can do about cleaning these up as well. Loading and Challenge do not seem synonymous: the challenge should not be altered until the fetch is complete, to prevent blank displays.

* web/flow: dedupe the set error flow state

# What

Extracts the logic for setting the flow state to FlowError.

# Why

It was just duplication. Trying to clean up state management is easier when special state handling is isolated into a single method.

* web/flow: dedupe the creation of fresh FlowApi instances

# What

Generates a single instance of FlowApi() that the FlowExecutor can use over the course of its lifetime.

# Why

Looking at the code generated by OpenApi, it’s clear that the parameters with which the API commits network transactions are immutable after construction; likewise, our particular invocation of `DEFAULT_GLOBALS` is also immutable with respect to a single instance of the FlowExecutor. With that in mind, there’s no reason to keep rebuilding the same network transaction object over and over; just instantiate it and live with it. In the conflict between rules-of-thumb “Never store what you can express” and “Extract repetitious expressions into instances,” the latter rule wins here.

* web/flow: clean up state representation in FlowExecutor (#20027)

* web/flow: clean up state representation in FlowExecutor

# What

Cleans up the state and lifecycle of FlowExecutor.

*As state lifecycle*, the two fields `challenge` and `flowInfo` are synonymous: they are modified at the same time, once in the setter, and once in `updated()`; flowInfo is always a derived consequence of that current challenge. Making `challenge` the property that we are monitoring and `flowInfo` a simple accessor on `challenge` eliminates duplication of state management.

Lit automatically schedules a re-render whenever `challenge` is changed; the `requestUpdate()` is therefore not needed.

With that, the only thing left is where or when to change the document title. That too is moved to `updated()` and happens without checking for need; it does no harm to replace a string with its own value, the performance loss is so small as to be non-existent, it will not confuse the browser or the environment. Eliminating an `if` and reducing the code surface to a pattern check is a win.

FlowExecutor now has only three states: Loading, Challenge Available, and… Inspector? Let’s see what we can do about cleaning these up as well. Loading and Challenge do not seem synonymous: the challenge should not be altered until the fetch is complete, to prevent blank displays.

* web/flow: dedupe the set error flow state (#20029)

* web/flow: dedupe the set error flow state

# What

Extracts the logic for setting the flow state to FlowError.

# Why

It was just duplication. Trying to clean up state management is easier when special state handling is isolated into a single method.

* Protected.

---------

Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>

---------

Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>

* Fix types.

* web: Flesh out module driven tag names.

* web/flow: optimize table for type safety

# What

Separate out the “here’s how a stage is defined” from “Here’s how a stage is represented internally.” This gives us a nice central store of where to define how the server-side componentName relates to a client-side customElementName while also guaranteeing that the componenName or supplied customElementName exists and corresponds. Type safety has been preserved system-wide (thanks, @GirlBossRush!)

* Tidy.

* Removed the cache; it's extra code for no benefit whatsoever; the table is constructed ONCE at start-up, there's never going to be a cache hit.  The FlowExecutorStageFactory produces StageMappings (StageMapping[]), which is itself a warehouse of singular server-component -> client-component relationships, fetching the client from the bundle as needed.  The StageMapping only does the fetch once per instance, so (for example) a password failure will reinstantiate a PasswordStage, but it will not fetch it a second time.

* Removed comments about the cache.  Added comments about where to find the FlowExecutor stage table. Moved the import of WebAuthnAuthenticticatorRegisterState from FlowExecutor.ts to FlowExecutorStages.ts; both files are bundled together, so this is a no-op functionally, but it's easier to confirm that StageEntries without import expressions (STageModuleCallbacks) have their stages bundled (pre-imported) if the import statement is in the same file.

* web: Flesh out stage mapping error handling. (#20292)

Co-authored-by: Ken Sternberg <ken@goauthentik.io>

---------

Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/maintenance/no-unknown-attributes-1

# What

This commit is a collection of fixes and adaptations discovered while running lit-analyzer in a stricter role than usual. These fixes are to 9 of the existing issues; there are 16 more that will be addressed in the next two pull requests.

The following issues were uncovered.

- `ak-slug-input` does not take `autocomplete`.
- `ak-wizard-page-type-create` does not take, or use, the `name` attribute. It also has no `value` of its own, so it is not processed as a form object.
- `ak-endpoints-device-access-groups-form` does not take a `pk` attribute. It takes an `.instancePk` property.
- `ak-provider-oauth2-redirect-uri` is only used in one place, and that place uses the term `input-id` for the key. The component was expected `inputId`. Since it is a string and therefore an attribute, kebab-case is the appropriate fix here.
- `input-mode` is not a valid attribute. The attribute is `inputmode`, and the property is `inputMode`. It may not be undefined. If it is defined, the default is `text`. I have fixed this in the attribute and in the two Forms that used it.
- `form-associated-element` had both `name` and `type` as readonly. Since they are native attributes, they can be attributes or they can be readonly. They can’t be both. I have made them read-write.
- `user-source-settings-page` is only used in one place, and that place uses the term `input-id` for the key. The component was expected `inputId`. Since it is a string and therefore an attribute, kebab-case is the appropriate fix here.

These guideposts will be placed on the PR.

* Update web/src/admin/providers/oauth2/OAuth2ProviderRedirectURI.ts

Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
Signed-off-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>

* Update web/src/components/ak-text-input.ts

Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
Signed-off-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>

* web/maintenance/no-unknown-attributes-2

# What

This commit is a collection of fixes and adaptations discovered while running lit-analyzer in a stricter role than usual.

- `src/admin/endpoints/connectors/agent/AgentConnectorSetup.ts`

After talking to @BeryJu, we determined that these labels aren’t shown and aren’t used.

- `src/admin/admin-overview/AdminOverviewPage.ts`
- `src/admin/admin-overview/DashboardUserPage.ts`
- `src/elements/cards/AggregatePromiseCard.ts`
- `src/elements/cards/stories/AggregatePromiseCard.stories.ts`

The `Promise` version of our card is not used by any client code. The Dashboard pages that were importing it want the vanilla `AggregateCard` instead.

- `./src/flow/stages/identification/IdentificationStage.ts`

Anchors do not have a `name` attribute, I cannot find any code using the name attributes as lookups, nor any CSS that might use the name attributes as guides. `ak-flow-password-input` is always required; the flag is unsupported and unnecessary.

- `./src/flow/stages/password/PasswordStage.ts`

Anchors do not have a `name` attribute, I cannot find any code using the name attributes as lookups, nor any CSS that might use the name attributes as guides. `ak-flow-password-input` is always required; the flag is unsupported and unnecessary.

- `src/user/user-settings/UserSettingsPage.ts`

This change to the `UserSettingsPage`:

``` diff
-                                userId=${ifPresent(currentUser?.pk)}
+                                user-id=${ifPresent(currentUser?.pk)}
```

… corresponds correctly with:

``` typescript
    @Property({ type: Number, attribute: "user-id" })
    public userId?: number;
```

I find it odd (and remarkable) that nobody has complained about this yet. I even went so far as to [confirm my understanding](https://codepen.io/kensternberg-authentik/pen/raLNBwO) and, yes:

- when an attribute is truthy, property syntax does not set the field
- when an attribute is deliberately given a kebab-case name, using the camelCase variant does not set the field

However, when the attribute is truthy, attribute names are case-insensitive: ‘user-id’ and ‘User-Id’ in client code would work just fine.

## Note

A large enough number of warnings remain. Some of those are due to `lit-analyzer` not being updated to recognize newly Baseline global DOM properties like `inert` or `popover`. The rest are from RapiDoc and QrCode, which do not supply sufficient documentation or metadata for Lit-anaylzer to read correctly.

* web/bug/hidden-secrets-not-propagating

# What

This commit updates ak-secret-text-input, adding the `name` attribute to all valid input fields and updating the value writer to match those of known-working components, to ensure that either variety of the display is fully and correctly updated with the content of the hidden secret.

# Why

The hidden input field is the one that HorizontalFormElement was expecting to read its value from, but that field never received a `name` because it wasn’t present when the field was first updated.

HorizontalFormElement writes the `name` field to the first `<input>` it finds. That was the “dummy” input field, which has no working value.

Form ignored the input element because the value it read came with an undefined name.

Object-oriented state management sometimes bites.

* Turns out, I was wrong. Someone *does* use the `name` attribute: the tests.  MDN says that `name`
is incorrect, and we should use `id` instead.  I have compromised; I have switched to using the
Open UI Automation ID instead, since that's what we're doing: automated tests.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

---------

Signed-off-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>
Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
Co-authored-by: Jens L. <jens@goauthentik.io>

…cle (#20063)

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/flow: refactor FlowExecutor so that client-side stage selection is separate from stage execution

# What

Extracts and normalizes the *massive* switch/case statement into a table, eliminating as much repetition as possible. Where the server-side stage token and the client-side component have the same tag, only one is required. There were three different patterns for prop definitions, and those have been regularized into an expression with a compile-time type check, and the most common one can be omitted from the stage definition table.

# Why

1.  Because it’s hella cleaner. Stages are clear and easy to spot in the table (especially when it’s alphabetically ordered, OMG). Stages that disagree in name with their components, stages that take props different from the “standard” set, and stages that need `import` statements, are all easy to identify.
2.  Because identifying what we *do* with our web components is critical to their success, and to the success of the styling system the authentik web team envisions. FlowExecutor provides selection and execution of stages, but it also provides the inspector, the locale selector, headers, footers, customizations, and branding. Clearing away clutter to make that easier to see makes future refactoring for compatibility mode and dark theme handling much easier.

* web/flow: clean up state representation in FlowExecutor

# What

Cleans up the state and lifecycle of FlowExecutor.

*As state lifecycle*, the two fields `challenge` and `flowInfo` are synonymous: they are modified at the same time, once in the setter, and once in `updated()`; flowInfo is always a derived consequence of that current challenge. Making `challenge` the property that we are monitoring and `flowInfo` a simple accessor on `challenge` eliminates duplication of state management.

Lit automatically schedules a re-render whenever `challenge` is changed; the `requestUpdate()` is therefore not needed.

With that, the only thing left is where or when to change the document title. That too is moved to `updated()` and happens without checking for need; it does no harm to replace a string with its own value, the performance loss is so small as to be non-existent, it will not confuse the browser or the environment. Eliminating an `if` and reducing the code surface to a pattern check is a win.

FlowExecutor now has only three states: Loading, Challenge Available, and… Inspector? Let’s see what we can do about cleaning these up as well. Loading and Challenge do not seem synonymous: the challenge should not be altered until the fetch is complete, to prevent blank displays.

* web/flow: dedupe the set error flow state

# What

Extracts the logic for setting the flow state to FlowError.

# Why

It was just duplication. Trying to clean up state management is easier when special state handling is isolated into a single method.

* web/flow: dedupe the creation of fresh FlowApi instances

# What

Generates a single instance of FlowApi() that the FlowExecutor can use over the course of its lifetime.

# Why

Looking at the code generated by OpenApi, it’s clear that the parameters with which the API commits network transactions are immutable after construction; likewise, our particular invocation of `DEFAULT_GLOBALS` is also immutable with respect to a single instance of the FlowExecutor. With that in mind, there’s no reason to keep rebuilding the same network transaction object over and over; just instantiate it and live with it. In the conflict between rules-of-thumb “Never store what you can express” and “Extract repetitious expressions into instances,” the latter rule wins here.

* Intermediate. Gonna check against results.

* web/flow: extract inspector into standalone lifecycle

# What

Removes all of the code from `FlowExecutor` related to the inspector and isolates it into its own component. The lifecycle of FlowExecutor’s inspector handling has been adjusted to maintain the existing behavior.

# How

FlowExecutor is reduced to merely presenting the button:

- In `FlowExecutor`:
  - Remove all the controls and references to FlowInspector
    - Remove the capabilities check
    - Remove the inspector listener
    - Remove the render guards
    - Remove the “inspect” PropVariant (and remove it from `FlowExecutorSelections`)
    - Remove the inspector toggle
    - Remove the inspector renderer
  - Always dispatch FlowAdvance events (if the inspector is not present they will be ignored)
  - Adjust `ak-stage-redirect` to not take “promptUser” as an attribute
  - Replace the whole render-inspector-button clause with `ak-flow-inspector-button`
  - Adjust CSS to use `ak-flow-inspector-button` instead of `.inspector-button`

RedirectStage now queries the context for inspector availability and state:

- In `stages/RedirectStage`:
  - Change `promptUser` from a property accessor to a simple accessor that queries the parent context for the inspector state
  - Remove the `@property` clause

FlowInspectorButton takes over these responsibilities, isolating this separate concern into a single file:

- Manages loaded, available, and open states
- Does the capabilities check
- Listens for FlowInspectorChangeEvents on the window object
- Renders nothing at all if the inspector is inaccessible or if the inspector is present and covering up the button
- On connectedCallback checks if the URL indicate the inspector should already be open
- Manages loading the FlowInspector on demand and toggles the drawer on state change

To my great surprise, `FlowInspector` itself required no changes.

* web/flow: clean up state representation in FlowExecutor (#20027)

* web/flow: clean up state representation in FlowExecutor

# What

Cleans up the state and lifecycle of FlowExecutor.

*As state lifecycle*, the two fields `challenge` and `flowInfo` are synonymous: they are modified at the same time, once in the setter, and once in `updated()`; flowInfo is always a derived consequence of that current challenge. Making `challenge` the property that we are monitoring and `flowInfo` a simple accessor on `challenge` eliminates duplication of state management.

Lit automatically schedules a re-render whenever `challenge` is changed; the `requestUpdate()` is therefore not needed.

With that, the only thing left is where or when to change the document title. That too is moved to `updated()` and happens without checking for need; it does no harm to replace a string with its own value, the performance loss is so small as to be non-existent, it will not confuse the browser or the environment. Eliminating an `if` and reducing the code surface to a pattern check is a win.

FlowExecutor now has only three states: Loading, Challenge Available, and… Inspector? Let’s see what we can do about cleaning these up as well. Loading and Challenge do not seem synonymous: the challenge should not be altered until the fetch is complete, to prevent blank displays.

* web/flow: dedupe the set error flow state (#20029)

* web/flow: dedupe the set error flow state

# What

Extracts the logic for setting the flow state to FlowError.

# Why

It was just duplication. Trying to clean up state management is easier when special state handling is isolated into a single method.

* Protected.

---------

Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>

---------

Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>

* Fix types.

* web: Flesh out module driven tag names.

* web/flow: optimize table for type safety

# What

Separate out the “here’s how a stage is defined” from “Here’s how a stage is represented internally.” This gives us a nice central store of where to define how the server-side componentName relates to a client-side customElementName while also guaranteeing that the componenName or supplied customElementName exists and corresponds. Type safety has been preserved system-wide (thanks, @GirlBossRush!)

* Prettier is still having opinions.

* Tidy.

* Removed the cache; it's extra code for no benefit whatsoever; the table is constructed ONCE at start-up, there's never going to be a cache hit.  The FlowExecutorStageFactory produces StageMappings (StageMapping[]), which is itself a warehouse of singular server-component -> client-component relationships, fetching the client from the bundle as needed.  The StageMapping only does the fetch once per instance, so (for example) a password failure will reinstantiate a PasswordStage, but it will not fetch it a second time.

* Removed comments about the cache.  Added comments about where to find the FlowExecutor stage table. Moved the import of WebAuthnAuthenticticatorRegisterState from FlowExecutor.ts to FlowExecutorStages.ts; both files are bundled together, so this is a no-op functionally, but it's easier to confirm that StageEntries without import expressions (STageModuleCallbacks) have their stages bundled (pre-imported) if the import statement is in the same file.

* Of COURSE prettier had opinions!

* Since the check for `this.can(CapabilitiesEnum.CanDebug))` has been moved into the FlowInspectorButton, FlowExecutor no longer needs the capabilities check at all.

* Move the inspector into its own folder.

* web: Flesh out stage mapping error handling. (#20292)

Co-authored-by: Ken Sternberg <ken@goauthentik.io>

* Weird merge bug: same function appeared twice.

---------

Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>

* web: Add InvalidationFlow to Radius Provider dialogues

## What

- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
  - Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
    to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`

## Note

Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.

* This (temporary) change is needed to prevent the unit tests from failing.

\# What

\# Why

\# How

\# Designs

\# Test Steps

\# Other Notes

* Revert "This (temporary) change is needed to prevent the unit tests from failing."

This reverts commit dddde09.

* website: fix bad escaping of URLs in release notes

## What

Fixes bad escaping of URLs in the release notes that resulted in mangled output.

v2024.6.4 had entries that looked like this:

```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```

v2025.4.md had entries that looked like this:

```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```

A couple of straightforward search-and-replaces has fixed the issue.

## Notes

Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.

@BeryJu suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.

The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.

* web/flow: refactor FlowExecutor so that client-side stage selection is separate from stage execution

# What

Extracts and normalizes the *massive* switch/case statement into a table, eliminating as much repetition as possible. Where the server-side stage token and the client-side component have the same tag, only one is required. There were three different patterns for prop definitions, and those have been regularized into an expression with a compile-time type check, and the most common one can be omitted from the stage definition table.

# Why

1.  Because it’s hella cleaner. Stages are clear and easy to spot in the table (especially when it’s alphabetically ordered, OMG). Stages that disagree in name with their components, stages that take props different from the “standard” set, and stages that need `import` statements, are all easy to identify.
2.  Because identifying what we *do* with our web components is critical to their success, and to the success of the styling system the authentik web team envisions. FlowExecutor provides selection and execution of stages, but it also provides the inspector, the locale selector, headers, footers, customizations, and branding. Clearing away clutter to make that easier to see makes future refactoring for compatibility mode and dark theme handling much easier.

* web/flow: clean up state representation in FlowExecutor

# What

Cleans up the state and lifecycle of FlowExecutor.

*As state lifecycle*, the two fields `challenge` and `flowInfo` are synonymous: they are modified at the same time, once in the setter, and once in `updated()`; flowInfo is always a derived consequence of that current challenge. Making `challenge` the property that we are monitoring and `flowInfo` a simple accessor on `challenge` eliminates duplication of state management.

Lit automatically schedules a re-render whenever `challenge` is changed; the `requestUpdate()` is therefore not needed.

With that, the only thing left is where or when to change the document title. That too is moved to `updated()` and happens without checking for need; it does no harm to replace a string with its own value, the performance loss is so small as to be non-existent, it will not confuse the browser or the environment. Eliminating an `if` and reducing the code surface to a pattern check is a win.

FlowExecutor now has only three states: Loading, Challenge Available, and… Inspector? Let’s see what we can do about cleaning these up as well. Loading and Challenge do not seem synonymous: the challenge should not be altered until the fetch is complete, to prevent blank displays.

* web/flow: dedupe the set error flow state

# What

Extracts the logic for setting the flow state to FlowError.

# Why

It was just duplication. Trying to clean up state management is easier when special state handling is isolated into a single method.

* web/flow: dedupe the creation of fresh FlowApi instances

# What

Generates a single instance of FlowApi() that the FlowExecutor can use over the course of its lifetime.

# Why

Looking at the code generated by OpenApi, it’s clear that the parameters with which the API commits network transactions are immutable after construction; likewise, our particular invocation of `DEFAULT_GLOBALS` is also immutable with respect to a single instance of the FlowExecutor. With that in mind, there’s no reason to keep rebuilding the same network transaction object over and over; just instantiate it and live with it. In the conflict between rules-of-thumb “Never store what you can express” and “Extract repetitious expressions into instances,” the latter rule wins here.

* Intermediate. Gonna check against results.

* web/flow: extract inspector into standalone lifecycle

# What

Removes all of the code from `FlowExecutor` related to the inspector and isolates it into its own component. The lifecycle of FlowExecutor’s inspector handling has been adjusted to maintain the existing behavior.

# How

FlowExecutor is reduced to merely presenting the button:

- In `FlowExecutor`:
  - Remove all the controls and references to FlowInspector
    - Remove the capabilities check
    - Remove the inspector listener
    - Remove the render guards
    - Remove the “inspect” PropVariant (and remove it from `FlowExecutorSelections`)
    - Remove the inspector toggle
    - Remove the inspector renderer
  - Always dispatch FlowAdvance events (if the inspector is not present they will be ignored)
  - Adjust `ak-stage-redirect` to not take “promptUser” as an attribute
  - Replace the whole render-inspector-button clause with `ak-flow-inspector-button`
  - Adjust CSS to use `ak-flow-inspector-button` instead of `.inspector-button`

RedirectStage now queries the context for inspector availability and state:

- In `stages/RedirectStage`:
  - Change `promptUser` from a property accessor to a simple accessor that queries the parent context for the inspector state
  - Remove the `@property` clause

FlowInspectorButton takes over these responsibilities, isolating this separate concern into a single file:

- Manages loaded, available, and open states
- Does the capabilities check
- Listens for FlowInspectorChangeEvents on the window object
- Renders nothing at all if the inspector is inaccessible or if the inspector is present and covering up the button
- On connectedCallback checks if the URL indicate the inspector should already be open
- Manages loading the FlowInspector on demand and toggles the drawer on state change

To my great surprise, `FlowInspector` itself required no changes.

* Initial experiment to move stages into the light.

* web/flow: clean up state representation in FlowExecutor (#20027)

* web/flow: clean up state representation in FlowExecutor

# What

Cleans up the state and lifecycle of FlowExecutor.

*As state lifecycle*, the two fields `challenge` and `flowInfo` are synonymous: they are modified at the same time, once in the setter, and once in `updated()`; flowInfo is always a derived consequence of that current challenge. Making `challenge` the property that we are monitoring and `flowInfo` a simple accessor on `challenge` eliminates duplication of state management.

Lit automatically schedules a re-render whenever `challenge` is changed; the `requestUpdate()` is therefore not needed.

With that, the only thing left is where or when to change the document title. That too is moved to `updated()` and happens without checking for need; it does no harm to replace a string with its own value, the performance loss is so small as to be non-existent, it will not confuse the browser or the environment. Eliminating an `if` and reducing the code surface to a pattern check is a win.

FlowExecutor now has only three states: Loading, Challenge Available, and… Inspector? Let’s see what we can do about cleaning these up as well. Loading and Challenge do not seem synonymous: the challenge should not be altered until the fetch is complete, to prevent blank displays.

* web/flow: dedupe the set error flow state (#20029)

* web/flow: dedupe the set error flow state

# What

Extracts the logic for setting the flow state to FlowError.

# Why

It was just duplication. Trying to clean up state management is easier when special state handling is isolated into a single method.

* Protected.

---------

Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>

---------

Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>

* Fix types.

* web: Flesh out module driven tag names.

* Experiment continues: first-tier into the light.

* web/flow: optimize table for type safety

# What

Separate out the “here’s how a stage is defined” from “Here’s how a stage is represented internally.” This gives us a nice central store of where to define how the server-side componentName relates to a client-side customElementName while also guaranteeing that the componenName or supplied customElementName exists and corresponds. Type safety has been preserved system-wide (thanks, @GirlBossRush!)

* Prettier is still having opinions.

* web/flow: re-arrange IdentificationStage for maintainability

# What

Every conditional section of the IdentificationStage has been separated out into its own individual render function. Where possible, the information passed to the renderer has been reduced to a bare minimum (i.e if the function only needed the `passwordlessUrl`, that’s the only thing that’s passed to it), which helps highlight some inconsistencies in the API.

# No change

This is a purely maintenance-level change to the code, to make it obvious what needs to be plumbed/corrected in order to expose our dialogs to password managers. No functionality has been changed.

# Why

Figuring out how to turn our web components into proper elements, where what they contain is not isolated from the view of password managers, requires pulling out the functionality into small, readable components.

# Future work

Doing this has exposed several fundamental issues:

- auto-redirect is a state change from one LoginChallenge to another under a collection of conditions available on the challenge, triggered when FlowExecutor writes a new challenge. “Which challenge?” in FlowExecutor ought to be handling this, not handing it off to IdentificationStage.

- Everything about Captcha is about Captcha. It ought to be in its own little state managing class, perhaps as a lit controller.

- The same is true about WebAuthn.

- `host` is doing very little work; at best, it’s receiving a “change this” or “submit that” message, which is an Event. Look forward to that.

* Tidy.

* Removed the cache; it's extra code for no benefit whatsoever; the table is constructed ONCE at start-up, there's never going to be a cache hit.  The FlowExecutorStageFactory produces StageMappings (StageMapping[]), which is itself a warehouse of singular server-component -> client-component relationships, fetching the client from the bundle as needed.  The StageMapping only does the fetch once per instance, so (for example) a password failure will reinstantiate a PasswordStage, but it will not fetch it a second time.

* Removed comments about the cache.  Added comments about where to find the FlowExecutor stage table. Moved the import of WebAuthnAuthenticticatorRegisterState from FlowExecutor.ts to FlowExecutorStages.ts; both files are bundled together, so this is a no-op functionally, but it's easier to confirm that StageEntries without import expressions (STageModuleCallbacks) have their stages bundled (pre-imported) if the import statement is in the same file.

* Of COURSE prettier had opinions!

* Since the check for `this.can(CapabilitiesEnum.CanDebug))` has been moved into the FlowInspectorButton, FlowExecutor no longer needs the capabilities check at all.

* Move the inspector into its own folder.

* web: Flesh out stage mapping error handling. (#20292)

Co-authored-by: Ken Sternberg <ken@goauthentik.io>

* Weird merge bug: same function appeared twice.

* Added some visibility keys, as per @GirlBossRush

---------

Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>