web/admin: fix display bug for assigned users in application bindings in the wizard (#13435)
* 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.
* web/admin: fix display bug for assigned users in application bindings in the wizard
## What
Modifies the type-of-binding detection algorithm to check if there's a user field and
that it's a number.
## Why
The original type-of-binding detector checked if the field was set and asserted that it was a string
of at least one character. Unfortunately, this doesn't work for `user`, where the primary key is an
integer. Changing the algorithm to "It's really a string with something in it, *or* it's a number,"
works.
## Testing
- Ensure you have at least one user you can use, and that user has a username.
- Navigate through the Application Wizard until you reach the binding page.
- Create a user binding
- See that the user shows up in the table.
Co-authored-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>
web/user: ensure modal container on user-settings page is min-height: 100% (#13402)
* 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.
* web/admin: ensure modal container on user-settings page is min-height: 100%
## What
Add a min-height and auto-scroll directives to the CSS for the main section of the user-settings
page.
```
+ .pf-c-page__main {
+ min-height: 100vw;
+ overflow-y: auto;
```
## Why
Without this, Safari refused to render any pop-up modals that were "centered" on the viewport but
were "beneath" the rendered content space of the container. As a result, users could not create new
access tokens or app passwords. This is arguably incorrect behavior on Safari's part, but 🤷♀️.
Adding `overflow-y: auto` on the container means that if the page is not long enough to host the
pop-up, it will be accessible via scrolling.
## Testing
- Using Safari, Visit the User->User Settings, click "Tokens and App Passwords" tab, and click
"Create Token" or "Create App Password"
- Observe that the dialog is now accessible.
## Related Issue:
- [Unable to create API token in Safari
#12891](https://github.com/goauthentik/authentik/issues/12891)
* Fix a really stupid typo.
Co-authored-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>
web: Indicate when caps-lock is active during password input. (#12733)
Determining the state of the caps-lock key can be tricky as we're
dependant on a user-provided input to set a value. Thus, our initial
state defaults to not display any warning until the first keystroke.
- Revise to better use lit-html.
Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
sources/oauth: add group sync for azure_ad (#12894)
* sources/oauth: add group sync for azure_ad
* make group sync optional
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Jens L. <jens@goauthentik.io>
web/user: fix opening application with Enter not respecting new tab setting (#13115)
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Jens L. <jens@goauthentik.io>
web/admin: update Application Wizard button placement (#12771)
* 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.
* web: Make using the wizard the default for new applications
# What
1. I removed the "Wizard Hint" bar and migrated the "Create With Wizard" button down to the default
position as "Create With Provider," moving the "Create" button to a secondary position.
Primary coloring has been kept for both.
2. Added an alert to the "Create" legacy dialog:
> Using this form will only create an Application. In order to authenticate with the application,
> you will have to manually pair it with a Provider.
3. Updated the subtitle on the Wizard dialog:
``` diff
- wizardDescription = msg("Create a new application");
+ wizardDescription = msg("Create a new application and configure a provider for it.");
```
4. Updated the User page so that, if the User is-a Administrator and the number of Applications in
the system is zero, the user will be invited to create a new Application using the Wizard rather
than the legacy Form:
```diff
renderNewAppButton() {
const href = paramURL("/core/applications", {
- createForm: true,
+ createWizard: true,
});
```
5. Fixed a bug where, on initial render, if the `this.brand` field was not available, an error would
appear in the console. The effects were usually harmless, as brand information came quickly and
filled in before the user could notice, but it looked bad in the debugger.
6. Fixed a bug in testing where the wizard page "Configure Policy Bindings" had been changed to
"Configure Policy/User/Group Binding".
# Testing
Since the wizard OUID didn't change (`data-ouia-component-id="start-application-wizard"`), the E2E
tests for "Application Wizard" completed without any substantial changes to the routine or to the
tests.
``` sh
npm run test:e2e:watch -- --spec ./tests/specs/new-application-by-wizard.ts
```
# User documentation changes required.
These changes were made at the request of docs, as an initial draft to show how the page looks with
the Application Wizard as he default tool for creating new Applications.
# Developer documentation changes required.
None.
Co-authored-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>
