* main: (21 commits)
web: manage stacked modals with a stack (#9193)
website/docs: ensure yaml code blocks have language tags (#9240)
blueprints: only create default brand if no other default brand exists (#9222)
web: bump API Client version (#9239)
website/integrations: portainer: Fix Redirect URL mismatch (#9226)
api: fix authentication schema (#9238)
translate: Updates for file web/xliff/en.xlf in zh_CN (#9229)
translate: Updates for file web/xliff/en.xlf in zh-Hans (#9230)
translate: Updates for file locale/en/LC_MESSAGES/django.po in zh_CN (#9228)
translate: Updates for file locale/en/LC_MESSAGES/django.po in zh-Hans (#9231)
core: bump pydantic from 2.6.4 to 2.7.0 (#9232)
core: bump ruff from 0.3.5 to 0.3.7 (#9233)
web: bump @sentry/browser from 7.109.0 to 7.110.0 in /web in the sentry group (#9234)
website: bump @types/react from 18.2.75 to 18.2.77 in /website (#9236)
core, web: update translations (#9225)
website/integrations: add pfSense search scope (#9221)
core: bump idna from 3.6 to 3.7 (#9224)
website/docs: add websocket support to nginx snippets (#9220)
internal: add tests to go flow executor (#9219)
website/integrations: nextcloud: add tip to solve hashed groups configuring OAuth2 (#9153)
...
* web: fix esbuild issue with style sheets
Getting ESBuild, Lit, and Storybook to all agree on how to read and parse stylesheets is a serious
pain. This fix better identifies the value types (instances) being passed from various sources in
the repo to the three *different* kinds of style processors we're using (the native one, the
polyfill one, and whatever the heck Storybook does internally).
Falling back to using older CSS instantiating techniques one era at a time seems to do the trick.
It's ugly, but in the face of the aggressive styling we use to avoid Flashes of Unstyled Content
(FLoUC), it's the logic with which we're left.
In standard mode, the following warning appears on the console when running a Flow:
```
Autofocus processing was blocked because a document already has a focused element.
```
In compatibility mode, the following **error** appears on the console when running a Flow:
```
crawler-inject.js:1106 Uncaught TypeError: Failed to execute 'observe' on 'MutationObserver': parameter 1 is not of type 'Node'.
at initDomMutationObservers (crawler-inject.js:1106:18)
at crawler-inject.js:1114:24
at Array.forEach (<anonymous>)
at initDomMutationObservers (crawler-inject.js:1114:10)
at crawler-inject.js:1549:1
initDomMutationObservers @ crawler-inject.js:1106
(anonymous) @ crawler-inject.js:1114
initDomMutationObservers @ crawler-inject.js:1114
(anonymous) @ crawler-inject.js:1549
```
Despite this error, nothing seems to be broken and flows work as anticipated.
* web: manage stacked modals with a stack
"Events flow up. Instructions flow down."
This commit creates a top-level listening controller associated with the main
Interface that listens for ModalShow events and registers the modal with a
stack. When it receives a corresponding KeyUp:Escape, it closes the topmost
modal and removes all references to that modal from the stack. When it receives
a ModalHide event, it removes all references to the target modal and removes all
references to that modal from the stack.
This commit includes a few new techniques. First, thanks to Justin Fagnani and
the Shoelace team, this commit includes an alternative technique for declaring
custom events by leveraging the GlobalEventHandlers type. This actually works
better: the event is explicit, easy to understand, and the typescript language
server actually gets them to correspond correctly; if you listen for a specific
custom event, the handler had better be of the right type to receive that
specific event!
Second, this introduces the first custom decorator, @bound(), which eliminates
the need to say `this.eventHandler = this.eventHandler.bind(this)` from event
handling methods that will have to be passed outside the `this` context of an
HTMLElement. After conducting several experiments to see if I understood the
PropertyDescriptor protocol correctly, I conclud that this is a safe technique
for wiring up `removeEventListener()` handlers.
* Prettier had opinions.
* web: manage stacked modals with a stack
By reviewer request, the `.closeModal()` protocol has been updated
so that if the method returns `false` (explicitly; `undefined` is
not `false`!), the `.closeModal()` protocol is aborted, the modal
remains at the top of the stack, and cleanup is not initiated.
Modal forms can now have an "are you sure?" pass if the user triggers
a close without saving the form. Figuring out how to close *two*
modals if the user *is* sure, and making the Form modal return `true`
when the user *is* sure, are left for a future exercise. :-)
* web: fix stack handling bug for `Escape`, and make Lint happier about loops
* main:
website/docs: add more info and links about enforciing unique email addresses (#9154)
core: bump goauthentik.io/api/v3 from 3.2024022.7 to 3.2024022.8 (#9215)
web: bump API Client version (#9214)
stages/authenticator_validate: add ability to limit webauthn device types (#9180)
web: bump API Client version (#9213)
core: add user settable token durations (#7410)
core, web: update translations (#9205)
web: bump typescript from 5.4.4 to 5.4.5 in /tests/wdio (#9206)
web: bump chromedriver from 123.0.2 to 123.0.3 in /tests/wdio (#9207)
core: bump sentry-sdk from 1.44.1 to 1.45.0 (#9208)
web: bump typescript from 5.4.4 to 5.4.5 in /web (#9209)
website: bump typescript from 5.4.4 to 5.4.5 in /website (#9210)
core: bump python from 3.12.2-slim-bookworm to 3.12.3-slim-bookworm (#9211)
* main:
translate: Updates for file locale/en/LC_MESSAGES/django.po in zh_CN (#9194)
translate: Updates for file locale/en/LC_MESSAGES/django.po in zh-Hans (#9197)
translate: Updates for file web/xliff/en.xlf in zh_CN (#9196)
translate: Updates for file web/xliff/en.xlf in zh-Hans (#9198)
web: preserve selected list when provider updates (#9200)
web: bump API Client version (#9195)
sources/oauth: make URLs not required, only check when no OIDC URLs are defined (#9182)
* web: fix esbuild issue with style sheets
Getting ESBuild, Lit, and Storybook to all agree on how to read and parse stylesheets is a serious
pain. This fix better identifies the value types (instances) being passed from various sources in
the repo to the three *different* kinds of style processors we're using (the native one, the
polyfill one, and whatever the heck Storybook does internally).
Falling back to using older CSS instantiating techniques one era at a time seems to do the trick.
It's ugly, but in the face of the aggressive styling we use to avoid Flashes of Unstyled Content
(FLoUC), it's the logic with which we're left.
In standard mode, the following warning appears on the console when running a Flow:
```
Autofocus processing was blocked because a document already has a focused element.
```
In compatibility mode, the following **error** appears on the console when running a Flow:
```
crawler-inject.js:1106 Uncaught TypeError: Failed to execute 'observe' on 'MutationObserver': parameter 1 is not of type 'Node'.
at initDomMutationObservers (crawler-inject.js:1106:18)
at crawler-inject.js:1114:24
at Array.forEach (<anonymous>)
at initDomMutationObservers (crawler-inject.js:1114:10)
at crawler-inject.js:1549:1
initDomMutationObservers @ crawler-inject.js:1106
(anonymous) @ crawler-inject.js:1114
initDomMutationObservers @ crawler-inject.js:1114
(anonymous) @ crawler-inject.js:1549
```
Despite this error, nothing seems to be broken and flows work as anticipated.
* web: preserve selected list when provider updates
The impulse to preserve the functionality of the system given a change of provider was... admirable,
but unnecessary in this case. A premature optimization that doesn't make a difference. Observations:
1. change from the client will bring a new `selected`. But changes from the outside shouldn't happen
once the interactive experience is "settled."
2. the client is perfectly capable of listening to the `change` event and reading the content of the
value list for selecteds. If the client is going to change the provider, it should provide the
most up-to-date copy of selecteds as well.
3. We set the selecteds from two locations: from the client on start-up, and from the "selected"
pane during user interaction. Anything more is risk. I shouldn't have taken that risk.
