* remove wrong help text for multi select
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* make labelling for create and and bind existing more consistent
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix oobe missing label
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix application library empty state not shown
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix missing formatting for title on access denied stage
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* 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: provide `show password` on login page
Provide a `show password` icon, text, and button for the password field both in the
IdentificationStage and the PasswordStage. Essentially the same code for both, although the id of
the password field is unique to each.
Requested by Cloudflare. Seems to be a common thing anyway.
Should it be an administrative option that this facility is available? From where should I derive
that information? I suspect the answer is "a site attribute," but I'd like to get confirmation.
* web: comment doesn't need to be exposed. It's sufficient where it is .
* web: fix button rendering issues
During testing, the buttons did not change as expected. We are using pure DOM
state to control the look of the button, and avoiding using `.requestUpdate()`
to avoid losing customer input, so depending upon Lit to re-render just the
button was an error.
This commit goes old-school and updates the button's label and icon using
standard DOM features, although we do lean into Lit-html`s `render()`
function to create the DOM component for the icon.
* web: provide `show password` on login page
Provide a `show password` icon, text, and button for the password field both in the
IdentificationStage and the PasswordStage. Essentially the same code for both, although the id of
the password field is unique to each.
Provide a configuration detail server-side to allow administrator to enable or disable the 'show
password' feature. Off by default.
Requested by Cloudflare. Seems to be a common thing anyway. Making it configurable wasn't in
Cloudfare's request, but it seemed logical to add.
* ensure the tests pass; quibbling over the wording of the admin field continues.
* Removed some manually identified fluff.
* web: break out `show password`-enabled input field into its own component
Provides a `show password` field, but as a LightDOM-oriented web component. This form of
input[type="password"] is for flows only, as it has a number of specializations for understanding a
flow's validating round-trip, possible error messages within the challenge, and is left within the
LightDOM both to support compatibility issues and to avoid using `elementInterals`, which is a DOM
feature not supported by some older browsers.
Avoids having to maintain two different instances of the same logic, both for permitting 'show
password', and for handling it.
* web: update PasswordStageForm according to lit-analyzer
With lit-analyzer in the mix and functional, we're seeing new complaints about
inconsistent typing in lit objects, and this was one of them.
* Another lit-analyze error found.
* 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: enhance search select
Patternfly doesn't even *have* a setting for "selected but not hovered," so I had to invent one. I
borrowed a trick from MUI and used the light blue "info" color, making it darker on
"selected+hovered."
This commit starts the revision process for search select. The goal is to have it broken down into
four major components: The inline-DOM component, which just shows the current value (or placeholder,
if none) and creates the portal for the floating component, then have a higher-level component for
the SearchSelect behavior, and a sidecar to manage the keyboard interactivity.
This is the portaled component: the actual list.
* web: enhance search select. Break menu and Input items into separate handlers.
* web: search select: added keyboard controller.
* web: search select - the isolation continues
This commit brings us to the position of having an independently rendered menu that listens for
click events on its contents, records the value internally *and* sends it upstream as an event.
This commit also includes a KeyboardController reactor that listens for keyboard events on a list of
objects, moving the focus up and down and sending a both a "selected" event when the user presses
Enter or Space, and a "close" event when the user presses Escape.
A lot of this is just infrastructure. None of these *do* very much; they're just tools for making
SearchSelect better.
AkSearchSelectView is next: it's responsible for rendering the input and menu items, and then for
forwarding the `value` component up to whoever cares.
`ak-search-select` will ultimately be responsible for fetching the data and mapping the string
tokens from AkSearchSelectView back into the objects that Authentik cares about.
* web: search select - a functioning search select
So search select is now separated into the following components:
- SearchSelectView: Takes the renderables and the selected() Value and draws the Value in a
box, then forwards the Options to a portaled drop-down component.
- SearchSelectMenuPosition: A web component that renders the Menu into the <BODY> element and
positions it with respect to an anchor provided by SearchSelectView.
- SearchSelectMenu: Renders the Menu and listens for events indicating an Item has been selected.
Sends events through a reference to the View.
- SearchKeyboardController: A specialized listener that keeps an independent list of indices and
tabstops, and listens for keyboard events to move the index forward or backward, as well as for
Event or Space for "select" and Escape for "close". Doesn't actually _do_ these things; they're
just semantics implied by the event names, it just sends an event up to the host, which can do
what it wants with them.
What's not done:
- SearchSelect: The interface with the API. Maps to and from API values to renderable Options.
One thing of note: of the 35 uses of SearchSelect in our product, 28 of them have `renderElement`
annotations of a single field. Six of them use the same annotation (renderFlow), and only one (in
EventMatcherPolicyForm) is at all complex. The 28 are:
- 7: group.name;
- 1: item.label;
- 5: item.name;
- 1: policy.name;
- 1: role.name;
- 1: source.name;
- 3: stage.name;
- 9: user.username;
I propose to modify `.renderElement` to take a string of `keyof T`, where T is the type passed to the
SearchSelect; it will simply look that up in the object passed in and use that as the Label.
`.renderDescription` is more or less similar, except it has _no_ special cases:
- 6: html`${flow.name}`;
- 1: html`${source.verboseName}`;
- 9: html`${user.name}`;
- 2: html`${flow.slug}`;
Given that, it makes sense to modify this as well to take a field key as a look up and render it,
making all that function calling somewhat moot.
Selected has a similar issue; passing it a value that is _not_ a function would be a signal to find
this specific element in the corresponding 'pk'. Or we could pass a tuple of [keyof T] and value,
so we didn't have to hard-code 'pk' into the thing.
- 1 return item.pk === this.instance?.createUsersGroup;
- 1 return item.pk === this.instance?.filterGroup;
- 2 return item.pk === this.instance?.group;
- 1 return item.pk === this.instance?.parent;
- 1 return item.pk === this.instance?.searchGroup;
- 1 return item.pk === this.instance?.syncParentGroup;
- 1 return item.pk === this.instance?.policy;
- 1 return item.pk === this.instance?.source;
- 1 return item.pk === this.instance?.passwordStage;
- 1 return item.pk === this.instance?.stage;
- 1 return item.pk === this.instance?.user;
- 2 return item.pk === this.previewUser?.pk;
- 5 return item.pk === this.instance?.configureFlow;
- 1 return item.pk === this.instance?.mapping;
- 1 return item.pk === this.instance?.nameIdMapping;
- 1 return item.pk === this.instance?.user;
- 1 return item.pk === this.instance?.webhookMapping;
- 1 return item.component === this.instance?.action;
- 1 return item.path === this.instance?.path;
- 1 return item.name === this.instance?.model;
- 1 return item.name === this.instance?.app;
- 1 return user.pk.toString() === this.request?.toString();
- 2 return this.request?.user.toString() === user.pk.toString();
And of course, `.value` kinda sorta has the same thing going on:
- 6: flow?.pk;
- 3: group ? group.pk : undefined;
- 4: group?.pk;
- 1: item?.component;
- 2: item?.name;
- 1: item?.path;
- 4: item?.pk;
- 1: policy?.pk;
- 1: role?.pk;
- 1: source?.pk;
- 3: stage?.pk;
- 8: user?.pk;
- 1: user?.username;
All in all, the _protocol_ for SearchSelect could be streamlined. A _lot_. And still retain the
existing power.
* Old take; not keeping.
* Didn't need this either.
* web: search select - a functioning search select with API interface
So many edge cases!
Because the propagation here is sometimes KeyboardEvent -> MenuEvent -> SearchSelectEvent, I had to
rename some of the events to prevent them from creating infinite loops of event handling. This
resulted in having to define separate events for Input, Close, and Select.
I struggled like heck to get the `<input>` object to show the value after updating. Ultimately, I
had to special case the `updated()` method to make sure it was showing the currently chosen display
value. Looking through Stack Overflow, there's a lot of contention about the meaning of the `value`
field on HTMLInputElements.
The API layer distinguishes between a "search" event, which triggers the query to run, and the
"select" event, which triggers the component to pick an object as _the_ `.value`.
The API layer handles the conversion to GroupedItems and makes sure that the View receives either
FlatSelect or GroupedSelect options collections (see ./types, but in practice users should never
care too much about this.)
* web: completed the search select update
* web: search-select reveals a weakness in our plans
While testing SearchSelect, I realized that the protocol for our "custom input elements" was
neither specified nor documented. I have attempted to fix that, and am finding edge cases
and buggy implementations that required addressing.
I've described the protocol by creating a class that implements it: AkControlElement. It
extends the constructor to always provide the "this is an data-ak-control element," and
provides a `json()` method that throws an exception in the base class, so it must always
be overriden and never called as super().
I've also fixed ak-dual-select so it carries its name properly into the Forms parser.
* web: search select (and friends)
This commit finalizes the search select quest! Headline: Search Select is now keyboard-friendly
*and* CSS friendly; the styling needed for position is small enough to fit in a `styleMap`, and the
styling for the menu itself can be safely locked into a web component.
Primarily, I was forgetting to map the value to its displayValue whenever the value was changed from
an external source. It should have been an easy catch, but I missed it the first dozen times
through.
* Not using this yet. ESLint-9 experiment that was loosely left here for some reason.
* Added lots of comments.
* Added new comments, fixed error message.
* Removing a console.log
* Fixed an incorrect comment.
* Added comments about workaround.
* web: focus fixes.
Fixes several issues with the drop-down, including primarily how "loss of focus"
does not result in the pop-up being banished. Also, the type definition for the
attribute `hidden` is inconsistent between Typescript, the attribute, and the
related property; I've chosen to route around that problem by using a custom
attribute and setting `hidden` in the template, where `lit-analyze` has a workable
definition and allows it to pass. Finally, on `open` the focus is passed to the
current value, if any.
* 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: all-aboard the anti-if bus, according to tooling
This commit revises a number of bugs `eslint` has been complaining about for awhile now. This is the
lesser of two PRs that will address this issue, and in this case the two biggest problems were
inappropriate conditionals (using a `switch` for a single comparison), unnecessarily named returns,
empty returns. This brings our use of conditions in-line with the coding standards we _say_ we want
in eslintrc!
* web: better names and logic for comparing the dates of Xliff vs generated files
* Missed one.
* Fixed a redirect issue that was creating an empty file in the ./web folder
* 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.
* root: fix migrations missing using db_alias
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* more
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* web: have no idea how this snuck through but I should have caught it.
---------
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
Co-authored-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
* 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: add more linting
* A reliable test for the extra code needed in analyzer, passing shellcheck
* web: re-enable custom-element-manifest and enable component checking in Typescript
This commit includes a monkeypatch to allow custom-element-manifest (CEM) to work correctly again
despite our rich collection of mixins, reactive controllers, symbol-oriented event handlers, and the
like. With that monkeypatch in place, we can now create the CEM manifest file and then exploit it so
that IDEs and the Typescript compilation pass can tell when a component is being used incorrectly;
when the wrong types are being passed to it, or when a required attribute is not initialized.
* Added building the manifest to the build process, rather than storing it. It is not appreciably slow.
* web: the most boring PR in the universe: Add HTMLTagNameElementMap to everyhing
This commit adds HTMLTagNameElementMap entries to every web component in the front end. Activating
and associating the HTMLTagNamElementMap with its class has enabled
[LitAnalyzer](https://github.com/runem/lit-analyzer/tree/master/packages/lit-analyzer) to reveal a
*lot* of basic problems within the UI, the most popular of which is "missing import." We usually get
away with it because the object being imported was already registered with the browser elsewhere,
but it still surprises me that we haven't gotten any complaints over things like:
```
./src/flow/stages/base.ts
Missing import for <ak-form-static>
96: <ak-form-static
no-missing-import
```
Given how early and fundamental that seems to be in our code, I'd have expected to hear _something_
about it.
I have not enabled most of the possible checks because, well, there are just a ton of warnings when
I do. I'd like to get in and fix those.
Aside from this, I have also _removed_ `customElement` declarations from anything declared as an
`abstract class`. It makes no sense to try and instantiate something that cannot, by definition, be
instantiated. If the class is capable of running on its own, it's not abstract, it just needs to be
overridden in child classes. Before removing the declaration I did check to make sure no other
piece of code was even *trying* to instantiate it, and so far I have detected no failures. Those
elements were:
- elements/forms/Form.ts
- element-/wizard/WizardFormPage.ts
The one that blows my mind, though, is this:
```
src/elements/forms/ProxyForm.ts
6-@customElement("ak-proxy-form")
7:export abstract class ProxyForm extends Form<unknown> {
```
Which, despite being `abstract`, is somehow instantiable?
```
src/admin/outposts/ServiceConnectionListPage.ts: <ak-proxy-form
src/admin/providers/ProviderListPage.ts: <ak-proxy-form
src/admin/sources/SourceWizard.ts: <ak-proxy-form
src/admin/sources/SourceListPage.ts: <ak-proxy-form
src/admin/providers/ProviderWizard.ts: <ak-proxy-form type=${type.component}></ak-proxy-form>
src/admin/stages/StageListPage.ts: <ak-proxy-form
```
I've made a note to investigate.
I've started a new folder where all of my one-off tools for *how* a certain PR was run. It has a
README describing what it's for, and the first tool, `add-htmlelementtagnamemaps-to-everything`, is
its first entry. That tool is also documented internally.
``` Gilbert & Sullivan
I've got a little list,
I've got a little list,
Of all the code that would never be missed,
The duplicate code of cute-and-paste,
The weak abstractions that lead to waste,
The embedded templates-- you get the gist,
There ain't none of 'em that will ever be missed,
And that's why I've got them on my list!
```
* 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: provide a test framework
As is typical of a system where a new build engine is involved, this thing is sadly fragile. Use the
wrong import style in wdio.conf.js and it breaks; there are several notes in tsconfig.test.conf and
wdio.conf.ts to tell eslint or tsc not to complain, it's just a different build with different
criteria, the native criteria don't apply.
On the other hand, writing tests is easy and predictable. We can test behaviors at the unit and
component scale in a straightforward manner, and validate our expectations that things work the way
we believe they should.
* Rolling back a reversion.
* web: update storybook, storybook a few things, fix a few things
After examining how people like Adobe and Salesforce do things, I have updated the storybook
configuration to provide run-time configuration of light/dark mode (although right now nothing
happens), inject the correct styling into the page, and update the preview handling so that we can
see the components better. We'll see how this pans out.
I have provided stories for the AggregateCard, AggregatePromiseCard, and a new QuickActionsCard. I
also fixed a bug in AggregatePromiseCard where it would fail to report a fetch error. It will only
report that "the operation falied," but it will give the full error into the console.
**As an experiment**, I have changed the interpreter for `lint:precommit` and `build:watch` to use
[Bun](https://bun.sh/) instead of NodeJS. We have observed significant speed-ups and much better
memory management with Bun for these two operations. Those are both developer-facing operations, the
behavior of the system undur current CI/CD should not change.
And finally, I've switched the QuickActionsCard view in Admin-Overview to use the new component.
Looks the same. Reads *way* easier. :-)
* Slight revision in exception logic.
* Added a ton of documentation; made the failure message configurable.
* A few documentation changes.
* Adjusting paths to work with tests.
* add ci to test
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* linting shenanigans
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* web: patch spotlight on the fly to fix syntax issue that blocked storybook build
This should be a temporary hack. I have an [open
issue](https://github.com/getsentry/spotlight/issues/419) and [pull
request](https://github.com/getsentry/spotlight/pull/420) with the
Spotlight people already to fix the issue.
* Somehow missed these in the merge.
* Merge missed something.
* Fix for incorrect path to patch file; fix for running patch multiple times.
* Prettier is still havin' opinions.
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>
* 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: replace multi-select with dual-select for all propertyMapping invocations
All of the uses of <select> to show propertyMappings have been replaced with an invocation to a
variant of dual select that allows for dynamic production of the "selected" list. Instead of giving
a "selected" list of elements, a "selector" function is passed that can, given the elements listed
by the provider, generated the "selected" list dynamically.
This feature is required for propertyMappings because many of the propertyMappings have an alternative
"default selected" feature whereby an object with no property mappings is automatically granted some
by the `.managed` field of the property mapping. The `DualSelectPair` type is now tragically
mis-named, as it it's now a 4-tuple, the fourth being whatever object or field is necessary to
figure out what the default value might be. For example, the Oauth2PropertyMappingsSelector looks
like this:
```
export function makeOAuth2PropertyMappingsSelector(instanceMappings: string[] | undefined) {
const localMappings = instanceMappings ? new Set(instanceMappings) : undefined;
return localMappings
? ([pk, _]: DualSelectPair) => localMappings.has(pk)
: ([_0, _1, _2, scope]: DualSelectPair<ScopeMapping>) =>
scope?.managed?.startsWith("goauthentik.io/providers/oauth2/scope-") &&
scope?.managed !== "goauthentik.io/providers/oauth2/scope-offline_access";
}
```
If there are instanceMappings, we create a Set of them and just look up the pk for "is this
selected" as we generate the component.
If there is not, we look at the `scope` object itself (Oauth2PropertyMappings were called "scopes"
in the original source) and perform a token analysis.
It works well, is reasonably fast, and reasonably memory-friendly.
In the case of RAC, OAuth2, and ProxyProviders, I've also provided external definitions of the
MappingProvider and MappingSelector, so that they can be shared between the Provider and the
ApplicationWizard.
The algorithm for finding the "alternative (default) selections" was *different* between the two
instances of both Oauth and Proxy. I'm not marking this as "ready" until Jens (@BeryJu) and I can go
over why that might have been so, and decide if using a common implementation for both is the
correct thing to do.
Also, a lot of this is (still) cut-and-paste; the dual-select invocation, and the definitions of
Providers and Selectors have a bit of boilerplate that it just didn't make sense to try and abstract
away; the code is DAMP (Descriptive and Meaningful Phrases), and I can live with it. Unfortunately,
that also points to the possibility of something being off; the wrong default token, or the wrong
phrase to describe the "Available" and "Selected" columns. So this is not (yet) ready for a full
pull review.
On the other hand, if this passes muster and we're happy with it, there are 11 more places to put
DualSelect, four of which are pure cut-and-paste lookups of the PaginatedOauthSourceList, plus a
miscellany of Prompts, Sources, Stages, Roles, EventTransports and Policies.
Despite the churn, the difference between the two implementations is 438 lines removed, 231 lines
added, 121 lines new. 86 LOC deleted. Could be better. :-)
* web: make the ...Selector semantics uniform across the definition set.
* web: fix proxy property mapping default criteria
* web: restoring dropped message to user.
* Ensuring the neccessary components are imported.
* web: fix problem with 'selector' overselecting
The 'selector' feature was overselecting, preventing items from
being removed from the "selected" list if they were part of the
host object. This has the shortcoming that `default` items *must*
be in the first page of options from the server, or they probably
won't be registered. Fortunately, that's currently the case.
* 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: add more linting
* A reliable test for the extra code needed in analyzer, passing shellcheck
* web: re-enable custom-element-manifest and enable component checking in Typescript
This commit includes a monkeypatch to allow custom-element-manifest (CEM) to work correctly again
despite our rich collection of mixins, reactive controllers, symbol-oriented event handlers, and the
like. With that monkeypatch in place, we can now create the CEM manifest file and then exploit it so
that IDEs and the Typescript compilation pass can tell when a component is being used incorrectly;
when the wrong types are being passed to it, or when a required attribute is not initialized.
* Added building the manifest to the build process, rather than storing it. It is not appreciably slow.
