mirror of
https://github.com/goauthentik/authentik
synced 2026-05-13 02:16:30 +02:00
1143de97d0
* 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 dddde09be5.
* 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