a8b33b25e874a8fde271f00c8c6de8b6ef9e518f
25 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| 752735d480 |
web: search select with focus, autocomplete, and progressive search (#10728)
* web: much better focus discipline Fix the way focus is handled in SearchSelect so that the drop-down isn't grabbing the focus away from the Input when the user wants to type in their selection. Because it was broken otherwise! There's still a bug where it's possible to type in a complete value *Label*, then leave the component's focus (input and menu) completely, in which case the Label remains, looking innocent and correct, but it is *not* reflective of the value as understood by the SearchSelect API controller. Gonna try to fix that next. But I'm saving this as a useful checkpoint. * . * root: insert daphne app in correct order Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: implement ak-list-select Creates a new element, ak-list-select, which is a scrollable list that reports when an element is clicked or selected by the keyboard. I was hideously over-engineering ak-search-select-menu, and I decided to try something simpler. This is that something. The events we care about are just "change" and "lost focus", and both of those can be attached by the parent regardless of portaling. * web: ak-list-select is complete An extraction of the "menu" and "list" features from SearchSelect and DualSelect, this is a very simplified version of a visible list that emulates the Radio/Select behavior (i.e only one from the collection may be "valued" at the time). It has no visible indicators of selection (aside from some highlighting), as it's meant to be used to present the list rather than be indicative of any state of the list. I was seriously over-engineering the menu. It turns out, it's just not that difficult after all. The only things we care about, really, are "did the user change the selection," "did the user click out of the list," and "did the user press the escape key." Those are pre-existing events (click w/value, blur, and keydown w/keycode, respectively), so there was no need for me to introduce new custom events to handler them. * web: downgrade sonarjs again, because dependabot Dammit, really need to tell that machine to leave our versions alone. * web: search select After a lot of testing and experimenting, it's finally starting to look stable. What a pain in the neck this has all been. * web: hold * web: search select with focus and progressive search - New component: ak-list-select, which allows you to select from a list of elements, with keyboard control. - New component: ak-portal, which manages elements by moving "slotted" content into a distant component, usually one attached to the body, and positions it relative to an existing element. - ak-search-select-view has been revamped to handle focus, change, input, and blur using the browser native event handlers, rather than inventing my own. - ak-search-select has been turned into a simple driver that manages the view. - ak-search-select has a new declarative syntax for the most common use case. I seriously over-engineered this thing, leaning too heavily on outdated knowledge or assumptions about how the browser works. The native event handlers attached at the component's borders works more than fine, and by attaching the event handlers to the portaled component before sending it off to the slots, the correct handlers get the message. This revision leverages the browser a *lot* more, and gets much more effective interaction with much less code. `<ak-list-select>` is a new component that replaces the ad-hoc menu object of the old SearchSelect. It is a standalone component that just shows a list, allows someone to navigate that list with the keyboard or the mouse. By default, it is limited to half the height of the viewport. The list does not have an indicator of "selected" at this time. That's just a side effect of it being developed as an adjunct to search-select. Its design does not preclude extension. It has a *lot* of CSS components that can be customized. The properties and events are documented, but there is only one event: `change`. Consistent with HTML, the value is not sent with the `change` event; clients are expected to extract it with `change:event.target.value`. Like all HTML components, it is completely stringly defined; the value is either a string or undefined. `<ak-portal>` is a somewhat specialized "portal" component that places an `ak-list-select` in an object on top of the existing DOM content. It can generalized to do this with any component, though, and can be extended. It has no events or CSS, since it's "just" managing the portaling relationship. `<ak-search-select-view>` is the heart of the system. It takes a collection options and behaves like an autocomplete component for them. The only unique event it sends out is `change`, and like `ak-list-select`, it expects the client to retrieve the value. Like all HTML components, it is completely stringly defined; the value is either a string or undefined. This is the SearchSelect component we've all known to come and love, but with a better pop-up and cleaner keyboard interaction. It emits only one event, `ak-change`, which *does* carry the value with it. The Storybooks have been updated to show the current version of Search Select, with a (simulated) API layer as well as more blunt stringly-typed tests for the View layer. A handful of tests have been provided to cover a number of edge cases that I discovered during testing. These run fine with the `npx` command, and I would love to see them integrated into CI/CD. The search select fields `renderElement`, `renderDescription`, and `value` properties of `ak-search-select` have been modified to take a string. For example, the search for the list of user looks like this: ``` <ak-search-select .fetchObjects=${async (query?: string): Promise<User[]> => { const args: CoreUsersListRequest = { ordering: "username" }; if (query !== undefined) { args.search = query; } const users = await new CoreApi(DEFAULT_CONFIG).coreUsersList(args); return users.results; }} .renderElement=${(user: User): string => { return user.username; }} .renderDescription=${(user: User): TemplateResult => { return html`${user.name}`; }} .value=${(user: User | undefined): string | undefined => { return user?.username; }} ></ak-search-select> ``` The most common syntax for the these three fields is "just return the string contents of a field by name," in the case of the description wrapped in a TemplateResult with no DOM components. By automating that initialization in the `connectedCallback` of the `ak-search-select` component, this object would look like: <ak-search-select .fetchObjects=${async (query?: string): Promise<User[]> => { const args: CoreUsersListRequest = { ordering: "username" }; if (query !== undefined) { args.search = query; } const users = await new CoreApi(DEFAULT_CONFIG).coreUsersList(args); return users.results; }} .renderElement=${"username"} .renderDescription=${"name"} .value=${"username"} ></ak-search-select> ``` Due to a limitation in the way properties (such as functions) are interpreted, the syntax `renderElement="username"` is invalid; it has to be a property expression. Sorry; best I could do. The old syntax works just fine. This is a "detect and extend at runtime" enhancement. * Added comments to the Component Driver Harness. * Added more safety and comments. * web: remove string-based access to API; replace with a consolidated "adapter" layer. Clean out the string-based API layer in SearchSelect. Break SearchSelect into a "Base" that does all the work, and then wrap it in two different front-ends: one that conforms to the old WCAPI, and one with a slightly new WCAPI: ``` <ak-search-select-ez .config=${{ fetchObjects: async (query?: string): Promise<Group[]> => { const args: CoreGroupsListRequest = { ordering: "name", includeUsers: false, }; if (query !== undefined) { args.search = query; } const groups = await new CoreApi(DEFAULT_CONFIG).coreGroupsList( args, ); return groups.results; }, renderElement: (group: Group): string => group.name, value: (group: Group | undefined): string | undefined => group?.pk, selected: (group: Group): boolean => group.pk === this.instance?.group }} blankable > </ak-search-select-ez> ``` * Prettier had opinions. In one case, an important opinion. * Rename test and fix lint error. * fix lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io> |
|||
| 2a2f1c3d3a |
web: replace all occurences of the theme placeholder (#10749)
Replace all occurences of the theme placeholder This allows the placeholder to occur multiple times in the theme url. Signed-off-by: Chasethechicken <neuringe1234@gmail.com> |
|||
| 7f0c6ddb5b |
web: fix dark theme and theme switch (#10667)
* base locale off of ak-element Signed-off-by: Jens Langhammer <jens@goauthentik.io> * revert temp theme fixes Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix theme switching Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add basic support for theme-different images Signed-off-by: Jens Langhammer <jens@goauthentik.io> * sort outposts in card Signed-off-by: Jens Langhammer <jens@goauthentik.io> * set default theme based on pre-hydrated brand settings Signed-off-by: Jens Langhammer <jens@goauthentik.io> * activate global theme before root in shadow dom Signed-off-by: Jens Langhammer <jens@goauthentik.io> * logging Signed-off-by: Jens Langhammer <jens@goauthentik.io> * when using _applyTheme, check media matcher Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add docs Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> |
|||
| ee58cf0c1c |
web: add HTMLTagNameElementMaps to everything to activate lit analyzer (#10217)
* 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!
```
|
|||
| f9fc32e89c |
web: fix esbuild issue with style sheets (#8856)
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.
|
|||
| 3981b55b40 |
web: replace rollup with esbuild (#8699)
* Holding for a moment... * web: replace rollup with esbuild This commit replaces rollup with esbuild. The biggest fix was to alter the way CSS is imported into our system; esbuild delivers it to the browser as text, rather than as a bundle with metadata that, frankly, we never use. ESBuild will bundle the CSS for us just fine, and interpreting those strings *as* CSS turned out to be a small hurdle. Code has been added to AKElement and Interface to ensure that all CSS referenced by an element has been converted to a Browser CSSStyleSheet before being presented to the browser. A similar fix has been provided for the markdown imports. The biggest headache there was that the re-arrangement of our documentation broke Jen's existing parser for fixing relative links. I've provided a corresponding hack that provides the necessary detail, but since the Markdown is being presented to the browser as text, we have to provide a hint in the markdown component for where any relative links should go, and we're importing and processing the markdown at runtime. This doesn't seem to be a big performance hit. The entire build process is driven by the new build script, `build.mjs`, which starts the esbuild process as a service connected to the build script and then runs the commands sent to it as fast as possible. The biggest "hack" in it is actually the replacement for rollup's `rollup-copy-plugin`, which is clever enough I'm surprised it doesn't exist as a standalone file-copy package in its own right. I've also used a filesystem watch library to encode a "watcher" mechanism into the build script. `node build.mjs --watch` will work on MacOS; I haven't tested it elsewhere, at least not yet. `node build.mjs --proxy` does what the old rollup.proxy.js script did. The savings are substantial. It takes less than two seconds to build the whole UI, a huge savings off the older ~45-50 seconds I routinely saw on my old Mac. It's also about 9% smaller. The trade-offs appear to be small: processing the CSS as StyleSheets, and the Markdown as HTML, at run-time is a small performance hit, but I didn't notice it in amongst everything else the UI does as it starts up. Manual chunking is gone; esbuild's support for that is quite difficult to get right compared to Rollup's, although there's been a bit of yelling at ESbuild over it. Codemirror is built into its own chunk; it's just not _named_ distinctly anymore. The one thing I haven't been able to test yet is whether or not the polyfills and runtim shims work as expected on older browsers. * web: continue with performance and build fixes This commit introduces a couple of fixes enabled by esbuild and other features. 1. build-locales `build-locales` is a new NodeJS script in the `./scripts` folder that does pretty much what it says in the name: it translates Xliff files into `.ts` files. It has two DevExp advantages over the old build system. First, it will check the build times of the xlf files and their ts equivalents, and will only run the actual build-locales command if the XLF files are newer than their TS equivalents. Second, it captures the stderr output from the build-locales command and summarizes it. Instead of the thousands of lines of "this string has no translation equivalent," now it just reports the number of missed translations per locale. 2. check-spelling This is a simple wrapper around the `codespell` command, mostly just to reduce the visual clutter of `package.json`, but also to permit it to run just about anywhere without needed hard-coded paths to the dictionaries, using a fairly classic trick with git. 3. pseudolocalize and import-maps These scripts were in TypeScript, but for our purposes I've saved their constructed equivalents instead. This saves on visual clutter in the `package.json` script, and reduced the time they have to run during full builds. They're small enough I feel confident they won't need too much looking over. Also, two lint bugs in Markdown.ts have been fixed. * Removed a few lines that weren't in use. * build-locales was sufficiently complex it needed some comments. * web: formalize that horrible unixy git status checker into a proper function. * Added types for , the Markdown processor for in-line documentation. * re-add dependencies required for storybook Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix optional deps Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix relative links for docs Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only build once on startup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent crash when build fails in watch mode, improve console output Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io> |
|||
| 5f1ba45966 |
web: provide dual-list multiselect with pagination (#8004)
* web: revise css-import-maps to need only a single entry, rather than dual-entry Given that the difference Vite/Storybook cares about is whether or not there's a sigil at the end of the CSS string, it seemed silly to require devs to enter both the raw and sigiled string; just do an in-line text-and-replace. * web: provide a "select / select all" tool for the dual list multiselect **This commit** Provides one of several of the sub-controls needed to make the multi-list multi-select thing work. This is the simplest control, and I decided to go with it first because it's all presentation; all it does is show the buttons and send events from those buttons. A Storybook component is provided to show how well it works. * web: provide a "select / select all" tool for the dual list multiselect **This commit** This commit provides the following new features for dual list multiselect: - The "available" pane, which has all of the entries that are available to be selected. Items that are already selected will remain, but they're marked with a checkmark and can neither be selected or moved. - The "selected" pane, which has *all* of the entries that have been selected. - The Pagination control, which in this case only sends an event upstream. **Plan**: The plan is to have a master control that marries the available-pane, selected-pane, select-controls, and pagination-controls into a single component that receives the list of "currently visible" available entries and keeps the list of "currently selected" entries, as well as a pass-through for the pagination value that allows it to hide the pagination control if there is only one page. A master component *above that* will provide the list of currently visible entries and, at need, read the value of the master control object for the "selected" list. That component will mostly be data-only; it's render will probably just be `<slot></slot>`; its duty will be only to map entries to string keys Lit can use, and to provide the lists we want to provide and the pagination ranges we want to show. Some judicious use of grid will allow me size the controls properly with/without the pagination control. Status and Title are going to be in the master control. A <slot> will be provided for Search, but I have no plans to integrate that into this control as of yet. There is already a planned fallback control; the multi-select experience on mobile is actually excellent, and we should exploit that appropriately. * web: provide a "select / select all" tool for the dual list multiselect **This commit** 1. Re-arrange the contents of the folder so that the sub-components are in their own folder. This reduces the clutter and makes it easier to understand where to look for certain things. 2. Re-arranges the contents of the folder so that all the Storybook stories are in their own folder. Again, this reduces the clutter; it also helps the compiler understand what not to compile. 3. Strips down the "Available items pane" to a minimal amount of interactivity and annotates the passed-in properties as `readonly`, since the purpose of this component is to display those. The only internal state kept is the list of items marked-to-move. 4. Does the same thing with the "Selected items pane". 5. Added comments to help guide future maintainers. 6. Restructured the CSS, taking a _lot_ of it into our own hands. Patternfly continues to act as if all components are fully available all the time, and that's simply not true in a shadowDOM environment. By separating out the global CSS Custom Properties from the grid and style definitions of `pf-c-dual-list-selector`, I was able to construct a more simple and straightforward grid (with nested grids for the columns inside). 7. Added "Delete ALL Selected" to the controls 8. Added "double-click" as a "move this one NOW" feature. * web: provide a "select / select all" tool for the dual list multiselect **This commit** - Fixes the bug whereby pagination would leave the 'some moves available' state visible by clearing the 'to-move' state when the list of options changes. - Fixes the bug whereby a change of 'options' in available would also cause an update to `selectedKeys`, causing the entire selected field to clear. Fixed by making `selectedKeys` a static object updated only when `selected` is generated rather than generating it anew with each re-rerender. (Hey, kids, can you say "functional programming and immutability" five time fast? I knew you could!) - Fixes the bug whereby the change of outpost type would not cause an update of the `options` collection. - Fixes the bug whereby the CSS was not creating enough whitespace separation between the whole component and its siblings. Host components are coded `span:static` unless otherwise styled to be `block`; we want `block` most of the time. - Fixes the bug whereby the list of existing objects wasn't being passed to the handler correctly. - Updates the Form Handler to recognize this new input object. - Fixes the bug whereby changing outpost type doesn't handle the list of selected applications well. - Fixes the bug whereby the identity of the outpost type's associated `fetch()` function loses identity -- necessary to maintain the selected outpost type switch. - Fixes the CSS bug whereby horizontal scrolling would not enable correctly when the application's name overflows the listbox. - Completes this assignment. :-) * web: last-minute pre-commit cleanup. * running localize extract * web: codeql found an issue with one of my tests. * web: multi-select Modified the display so that if it's a template we display it correctly opposite the text, and provide classes that can be used in the display to differentiate between the main label and the descriptive label. Added a sort key, so the select can sort the right-hand pane correctly. Fixed the `this.selected` setters to use Arrays instead of maps. Theoretically, this is terribly inefficient, as it makes it theoretically O(n^2) rather than O(1), but in practice even if both lists were 10,000 elements long a modern desktop could perform the entire scan in 150ms or so. * fix lint error Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update strings slightly Signed-off-by: Jens Langhammer <jens@goauthentik.io> * start on dark theme support Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: Add searchbar and enable it for "selected" "Available" requires a round-trip to the provider level, so that's next. * web: provide a search for the dual list multiselect **This commit** - Includes a new widget that represents the basic, Patternfly-designed search bar. It just emits events of search request updates. - Changes the definition of a data provider to take an optional search string. - Changes the handler in the *independent* layer so that it catches search requests and those requests work on the "selected" collection. - Changes the handler of the `authentik` interface layer so that it catches search requests and those requests are sent to the data provider. - Provides a debounce function for the `authentik` interface layer to not hammer the Django instance too much. - Updates the data providers in the example for `OutpostForm` to handle search requests. - Provides a property in the `authentik` interface layer so that the debounce can be tuned. * web: always trim the search string passed. * web: code quality pass, extra comments, pre-commit check. * Serious (and bizarre) merge bug. I guess it doesn't like XML that much. * Attempting to reason with whatever eslint GitHub is using. * Prettier has opinions. * Enable better dark mode. There were two issues: the dark mode didn't reach into the "search" bar, and there were several hover states that weren't handled well. This commit handles both. The color scheme mirrors the one we currently use, but it's a bit backwards from Patternfly 5. Dunno how we're gonna reconcile all that. * Prettier fixes and locale extraction * web: update pagination type to use generic, provided type * web: fixed a few comment typos * Discordant version numbers for @go-authentik/api were causing build failures. * What is up with CI/CD? * web: missed a lint issue that prevented the build from running successfully --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io> |
|||
| d555c0db41 |
web: abstract rootInterface()?.config?.capabilities.includes() into .can() (#7737)
* This commit abstracts access to the object `rootInterface()?.config?` into a single accessor,
`authentikConfig`, that can be mixed into any AKElement object that requires access to it.
Since access to `rootInterface()?.config?` is _universally_ used for a single (and repetitive)
boolean check, a separate accessor has been provided that converts all calls of the form:
``` javascript
rootInterface()?.config?.capabilities.includes(CapabilitiesEnum.CanImpersonate)
```
into:
``` javascript
this.can(CapabilitiesEnum.CanImpersonate)
```
It does this via a Mixin, `WithCapabilitiesConfig`, which understands that these calls only make
sense in the context of a running, fully configured authentik instance, and that their purpose is to
inform authentik components of a user’s capabilities. The latter is why I don’t feel uncomfortable
turning a function call into a method; we should make it explicit that this is a relationship
between components.
The mixin has a single single field, `[WCC.capabilitiesConfig]`, where its association with the
upper-level configuration is made. If that syntax looks peculiar to you, good! I’ve used an explict
unique symbol as the field name; it is inaccessable an innumerable in the object list. The debugger
shows it only as:
Symbol(): {
cacheTimeout: 300
cacheTimeoutFlows: 300
cacheTimeoutPolicies: 300
cacheTimeoutReputation: 300
capabilities: (5) ['can_save_media', 'can_geo_ip', 'can_impersonate', 'can_debug', 'is_enterprise']
}
Since you can’t reference it by identity, you can’t write to it. Until every browser supports actual
private fields, this is the best we can do; it does guarantee that field name collisions are
impossible, which is a win.
The mixin takes a second optional boolean; setting this to true will cause any web component using
the mixin to automatically schedule a re-render if the capabilities list changes.
The mixin is also generic; despite the "...into a Lit-Context" in the title, the internals of the
Mixin can be replaced with anything so long as the signature of `.can()` is preserved.
Because this work builds off the work I did to give the Sidebar access to the configuration without
ad-hoc retrieval or prop-drilling, it wasn’t necessary to create a new context for it. That will be
necessary for the following:
TODO:
``` javascript
rootInterface()?.uiConfig;
rootInterface()?.tenant;
me();
```
* web: Added a README with a description of the applications' "mental model," essentially an architectural description.
* web: prettier had opinions about the README
* web: Jens requested that subscription be by default, and it's the right call.
* This commit abstracts access to the object `rootInterface()?.config?` into a single accessor,
`authentikConfig`, that can be mixed into any AKElement object that requires access to it.
Since access to `rootInterface()?.config?` is _universally_ used for a single (and repetitive)
boolean check, a separate accessor has been provided that converts all calls of the form:
``` javascript
rootInterface()?.config?.capabilities.includes(CapabilitiesEnum.CanImpersonate)
```
into:
``` javascript
this.can(CapabilitiesEnum.CanImpersonate)
```
It does this via a Mixin, `WithCapabilitiesConfig`, which understands that these calls only make
sense in the context of a running, fully configured authentik instance, and that their purpose is to
inform authentik components of a user’s capabilities. The latter is why I don’t feel uncomfortable
turning a function call into a method; we should make it explicit that this is a relationship
between components.
The mixin has a single single field, `[WCC.capabilitiesConfig]`, where its association with the
upper-level configuration is made. If that syntax looks peculiar to you, good! I’ve used an explict
unique symbol as the field name; it is inaccessable an innumerable in the object list. The debugger
shows it only as:
Symbol(): {
cacheTimeout: 300
cacheTimeoutFlows: 300
cacheTimeoutPolicies: 300
cacheTimeoutReputation: 300
capabilities: (5) ['can_save_media', 'can_geo_ip', 'can_impersonate', 'can_debug', 'is_enterprise']
}
Since you can’t reference it by identity, you can’t write to it. Until every browser supports actual
private fields, this is the best we can do; it does guarantee that field name collisions are
impossible, which is a win.
The mixin takes a second optional boolean; setting this to true will cause any web component using
the mixin to automatically schedule a re-render if the capabilities list changes.
The mixin is also generic; despite the "...into a Lit-Context" in the title, the internals of the
Mixin can be replaced with anything so long as the signature of `.can()` is preserved.
Because this work builds off the work I did to give the Sidebar access to the configuration without
ad-hoc retrieval or prop-drilling, it wasn’t necessary to create a new context for it. That will be
necessary for the following:
TODO:
``` javascript
rootInterface()?.uiConfig;
rootInterface()?.tenant;
me();
```
* web: Added a README with a description of the applications' "mental model," essentially an architectural description.
* web: prettier had opinions about the README
* web: Jens requested that subscription be by default, and it's the right call.
* web: adjust RAC to point to the (now independent) Interface.
- Also, removed redundant check.
|
|||
| bb52765f51 |
web: refactor sidebar capabilities for categorical subsections (#7482)
* web: break circular dependency between AKElement & Interface.
This commit changes the way the root node of the web application shell is
discovered by child components, such that the base class shared by both
no longer results in a circular dependency between the two models.
I've run this in isolation and have seen no failures of discovery; the identity
token exists as soon as the Interface is constructed and is found by every item
on the page.
* web: fix broken typescript references
This built... and then it didn't? Anyway, the current fix is to
provide type information the AkInterface for the data that consumers
require.
* web: rollback dependabot's upgrade of context
The most frustrating part of this is that I RAN THIS, dammit, with the updated
context and the current Wizard, and it finished the End-to-End tests without
complaint.
* Due for amendment
* Revert "Due for amendment"
This reverts commit
|
|||
| 7e536515c6 |
web: isolate clipboard handling (#7229)
We would like to use the clipboard for more than just the token copy button. This commit enables that by separating the "Write to Clipboard" and "Write to Notifications" routines into separate functions, putting "writeToClipboard" into the utilities collection, and clarifying what happens when a custom presses the TokenCopy button. |
|||
| 6792bf8876 |
web: package up horizontal elements into their own components (#7053)
* web: laying the groundwork for future expansion This commit is a hodge-podge of updates and changes to the web. Functional changes: - Makefile: Fixed a bug in the `help` section that prevented the WIDTH from being accurately calculated if `help` was included rather than in-lined. - ESLint: Modified the "unused vars" rule so that variables starting with an underline are not considered by the rule. This allows for elided variables in event handlers. It's not a perfect solution-- a better one would be to use Typescript's function-specialization typing, but there are too many places where we elide or ignore some variables in a function's usage that switching over to specialization would be a huge lift. - locale: It turns out, lit-locale does its own context management. We don't need to have a context at all in this space, and that's one less listener we need to attach t othe DOM. - ModalButton: A small thing, but using `nothing` instead of "html``" allows lit better control over rendering and reduces the number of actual renders of the page. - FormGroup: Provided a means to modify the aria-label, rather than stick with the just the word "Details." Specializing this field will both help users of screen readers in the future, and will allow test suites to find specific form groups now. - RadioButton: provide a more consistent interface to the RadioButton. First, we dispatch the events to the outside world, and we set the value locally so that the current `Form.ts` continues to behave as expected. We also prevent the "button lost value" event from propagating; this presents a unified select-like interface to users of the RadioButtonGroup. The current value semantics are preserved; other clients of the RadioButton do not see a change in behavior. - EventEmitter: If the custom event detail is *not* an object, do not use the object-like semantics for forwarding it; just send it as-is. - Comments: In the course of laying the groundwork for the application wizard, I throw a LOT of comments into the code, describing APIs, interfaces, class and function signatures, to better document the behavior inside and as signposts for future work. * web: permit arrays to be sent in custom events without interpolation. * actually use assignValue or rather serializeFieldRecursive Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: package up horizontal elements into their own components. This commit introduces a number of "components." Jens has this idiom: ``` <ak-form-element-horizontal label=${msg("Name")} name="name" ?required=${true}> <input type="text" value="${ifDefined(this.instance?.name)}" class="pf-c-form-control" required /> </ak-form-element-horizontal> ``` It's a very web-oriented idiom in that it's built out of two building blocks, the "element-horizontal" descriptor, and the input object itself. This idiom is repeated a lot throughout the code. As an alternative, let's wrap everything into an inheritable interface: ``` <ak-text-input name="name" label=${msg("Name")} value="${ifDefined(this.instance?.name)} required > </ak-text-input> ``` This preserves all the information of the above, makes it much clearer what kind of interaction we're having (sometimes the `type=` information in an input is lost or easily missed), and while it does require you know that there are provided components rather than the pair of layout-behavior as in the original it also gives the developer more precision over the look and feel of the components. *Right now* these components are placed into the LightDOM, as they are in the existing source code, because the Form handler has a need to be able to "peer into" the "element-horizontal" component to find the values of the input objects. In a future revision I hope to place the burden of type/value processing onto the input objects themselves such that the form handler will need only look for the `.value` of the associated input control. Other fixes: - update the FlowSearch() such that it actually emits an input event when its value changes. - Disable the storybook shortcuts; on Chrome, at least, they get confused with simple inputs - Fix an issue with precommit to not scan any Python with ESLint! :-) * web: provide storybook stories for the components This commit provides storybook stories for the ak-horizontal-element wrappers. A few bugs were found along the way, including one rather nasty one from Radio where we were still getting the "set/unset" pair in the wrong order, so I had to knuckle down and fix the event handler properly. * web: test oauth2 provider "guinea pig" for new components I used the Oauth2 provider page as my experiment in seeing if the horizontal-element wrappers could be used instead of the raw wrappers themselves, and I wanted to make sure a test existed that asserts that filling out THAT form in the ProvidersList and ProvidersForm didn't break anything. This commit updates the WDIO tests to do just that; the test is simple, but it does exercise the `name` field of the Provider, something not needed in the Wizard because it's set automatically based on the Application name, and it even asserts that the new Provider exists in the list of available Providers when it's done. * web: making sure ESlint and Prettier are happy * "fix" lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io> |
|||
| 3b171a02b7 |
web: laying the groundwork for future expansion (#7045)
* web: laying the groundwork for future expansion This commit is a hodge-podge of updates and changes to the web. Functional changes: - Makefile: Fixed a bug in the `help` section that prevented the WIDTH from being accurately calculated if `help` was included rather than in-lined. - ESLint: Modified the "unused vars" rule so that variables starting with an underline are not considered by the rule. This allows for elided variables in event handlers. It's not a perfect solution-- a better one would be to use Typescript's function-specialization typing, but there are too many places where we elide or ignore some variables in a function's usage that switching over to specialization would be a huge lift. - locale: It turns out, lit-locale does its own context management. We don't need to have a context at all in this space, and that's one less listener we need to attach t othe DOM. - ModalButton: A small thing, but using `nothing` instead of "html``" allows lit better control over rendering and reduces the number of actual renders of the page. - FormGroup: Provided a means to modify the aria-label, rather than stick with the just the word "Details." Specializing this field will both help users of screen readers in the future, and will allow test suites to find specific form groups now. - RadioButton: provide a more consistent interface to the RadioButton. First, we dispatch the events to the outside world, and we set the value locally so that the current `Form.ts` continues to behave as expected. We also prevent the "button lost value" event from propagating; this presents a unified select-like interface to users of the RadioButtonGroup. The current value semantics are preserved; other clients of the RadioButton do not see a change in behavior. - EventEmitter: If the custom event detail is *not* an object, do not use the object-like semantics for forwarding it; just send it as-is. - Comments: In the course of laying the groundwork for the application wizard, I throw a LOT of comments into the code, describing APIs, interfaces, class and function signatures, to better document the behavior inside and as signposts for future work. * web: permit arrays to be sent in custom events without interpolation. * actually use assignValue or rather serializeFieldRecursive Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io> |
|||
| 8079952d47 |
web: rework and expand tooltips (#6435)
* web: replace custom tooltip with pfe-tooltip Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to all edit buttons Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add tooltips to remaining table actions Signed-off-by: Jens Langhammer <jens@goauthentik.io> * add a bunch more tooltips Signed-off-by: Jens Langhammer <jens@goauthentik.io> * update locale Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> |
|||
| 3f02534eb1 |
web: weightloss program, part 1: FlowSearch (#6332)
* web: weightloss program, part 1: FlowSearch
This commit extracts the multiple uses of SearchSelect for Flow lookups in the `providers`
collection and replaces them with a slightly more legible format, from:
```HTML
<ak-search-select
.fetchObjects=${async (query?: string): Promise<Flow[]> => {
const args: FlowsInstancesListRequest = {
ordering: "slug",
designation: FlowsInstancesListDesignationEnum.Authentication,
};
if (query !== undefined) {
args.search = query;
}
const flows = await new FlowsApi(DEFAULT_CONFIG).flowsInstancesList(args);
return flows.results;
}}
.renderElement=${(flow: Flow): string => {
return RenderFlowOption(flow);
}}
.renderDescription=${(flow: Flow): TemplateResult => {
return html`${flow.name}`;
}}
.value=${(flow: Flow | undefined): string | undefined => {
return flow?.pk;
}}
.selected=${(flow: Flow): boolean => {
return flow.pk === this.instance?.authenticationFlow;
}}
>
</ak-search-select>
```
... to:
```HTML
<ak-flow-search
flowType=${FlowsInstancesListDesignationEnum.Authentication}
.currentFlow=${this.instance?.authenticationFlow}
required
></ak-flow-search>
```
All of those middle methods, like `renderElement`, `renderDescription`, etc, are *completely the
same* for *all* of the searches, and there are something like 25 of them; this commit only covers
the 8 in `providers`, but the next commit should carry all of them.
The topmost example has been extracted into its own Web Component, `ak-flow-search`, that takes only
two arguments: the type of `FlowInstanceListDesignation` and the current instance of the flow.
The static methods for `renderElement`, `renderDescription` and `value` (which are all the same in
all 25 instances of `FlowInstancesListRequest`) have been made into standalone functions.
`fetchObjects` has been made into a method that takes the parameter from the `designation` property,
and `selected` has been turned into a method that takes the comparator instance from the
`currentFlow` property. That's it. That's the whole of it.
`SearchSelect` now emits an event whenever the user changes the field, and `ak-flow-search`
intercepts that event to mirror the value locally.
`Form` has been adapted to recognize the `ak-flow-search` element and extract the current value.
There are a number of legibility issues remaining, even with this fix. The Authentik Form manager
is dependent upon a component named `ak-form-element-horizontal`, which is a container for a single
displayed element in a form:
```HTML
<ak-form-element-horizontal
label=${msg("Authorization flow")}
?required=${true}
name="authorizationFlow"
>
<ak-flow-search
flowType=${FlowsInstancesListDesignationEnum.Authorization}
.currentFlow=${this.instance?.authorizationFlow}
required
></ak-flow-search>
<p class="pf-c-form__helper-text">
${msg("Flow used when authorizing this provider.")}
</p>
</ak-form-element-horizontal>
```
Imagine, instead, if we could write:
```HTML
<ak-form-element-flow-search
flowType=${FlowsInstancesListDesignationEnum.Authorization}
.currentFlow=${this.instance?.authorizationFlow}
required
name="authorizationFlow">
<label slot="label">${msg("Authorization flow")}</label>
<span slot="help">${msg("Flow used when authorizing this provider.")}</span>
<ak-form-element-flow-search>
```
Starting with a superclass that understands the need for `label` and `help` slots, it would
automatically configure the input object that would be used. We've already specified multiple
identical copies of this thing in multiple different places; centralizing their definition and then
re-using them would be classic code re-use.
Even better, since the Authorization flow is used 10 times in the whole of our code base, and the
Authentication flow 8 times, and they are *all identical*, it would be fitting if we just created
wrappers:
```HTML
<ak-form-element-flow-search
flowType=${FlowsInstancesListDesignationEnum.Authorization}>
<ak-form-element-flow-search>
```
That's really all that's needed. There are *hundreds* (about 470 total) cases where nine or more
lines of repetitious HTML could be replaced with a one-liner like the above.
A "narrow waist" design is one that allows for a system to communicate between two different
components through a small but consistent collection of calls. The Form manager needs to be narrowed
hard. The `ak-form-element-horizontal` is a wrapper around an input object, and it has this at its
core for extracting that information. This forwards the name component to the containing input
object so that when the input object generates an event, we can identify the field it's associated
with.
```Javascript
this.querySelectorAll("*").forEach((input) => {
switch (input.tagName.toLowerCase()) {
case "input":
case "textarea":
case "select":
case "ak-codemirror":
case "ak-chip-group":
case "ak-search-select":
case "ak-radio":
input.setAttribute("name", this.name);
break;
default:
return;
}
```
A *temporary* variant of this is in the `ak-flow-search` component, to support this API without
having to modify `ak-form-element-horizontal`.
And then `ak-form` itself has this:
```Javascript
if (
inputElement.tagName.toLowerCase() === "select" &&
"multiple" in inputElement.attributes
) {
const selectElement = inputElement as unknown as HTMLSelectElement;
json[element.name] = Array.from(selectElement.selectedOptions).map((v) => v.value);
} else if (
inputElement.tagName.toLowerCase() === "input" &&
inputElement.type === "date"
) {
json[element.name] = inputElement.valueAsDate;
} else if (
inputElement.tagName.toLowerCase() === "input" &&
inputElement.type === "datetime-local"
) {
json[element.name] = new Date(inputElement.valueAsNumber);
}
// ... another 20 lines removed
```
This ought to read:
```Javascript
const json = elements.filter((element => element instanceof AkFormComponent)
.reduce((acc, element) => ({ ...acc, [element.name]: element.value] });
```
Where, instead of hand-writing all the different input objects for date and datetime and checkbox
into our forms, and then having to craft custom value extractors for each and every one of them,
just write *one* version of each with all the wrappers and bells and whistles already attached, and
have each one of them have a `value` getter descriptor that returns the value expected by our form
handler.
A back-of-the-envelope estimation is that there's about four *thousand* lines that could disappear
if we did this right.
More importantly, it would be possible to create new `AkFormComponent`s without having to register
them or define them for `ak-form`; as long as they conformed to the AkFormComponent's expectations
for "what is a source of values for a Form", `ak-form` would understand how to handle it.
Ultimately, what I want is to be able to do this:
``` HTML
<ak-input-form
itemtype="ak-search"
itemid="ak-authentication"
itemprop=${this.instance}></ak-inputform>
```
And it will (1) go out and find the right kind of search to put there, (2) conduct the right kind of
fetch to fill that search, (3) pre-configure it with the user's current choice in that locale.
I don't think this is possible-- for one thing, it would be very expensive in terms of development,
and it may break the "narrow waist" ideal by require that the `ak-input-form` object know all the
different kinds of searches that are available. The old Midgardian dream was that the object would
have *just* the identity triple (A table, a row of that table, a field of that row), and the
Javascript would go out and, using the identity, *find* the right object for CRUD (Creating,
Retrieving, Updating, and Deleting) it.
But that inspiration, as unreachable as it is, is where I'm headed. Where our objects are both
*smart* and *standalone*. Where they're polite citizens in an ordered universe, capable of
independence sufficient to be tested and validated and trusted, but working in concert to achieve
our aims.
* web: unravel the search-select for flows completely.
This commit removes *all* instances of the search-select
for flows, classifying them into four different categories:
- a search with no default
- a search with a default
- a search with a default and a fallback to a static default if non specified
- a search with a default and a fallback to the tenant's preferred default if this is a new instance
and no flow specified.
It's not humanly possible to test all the instances where this has been committed, but the linters
are very happy with the results, and I'm going to eyeball every one of them in the github
presentation before I move this out of draft.
* web: several were declared 'required' that were not.
* web: I can't believe this was rejected because of a misspelling in a code comment. Well done\!
* web: another codespell fix for a comment.
* web: adding 'codespell' to the pre-commit command. Fixed spelling error in eventEmitter.
|
|||
| 12c4ac704f |
web: basic cleanup of buttons (#6107)
* web: basic cleanup of buttons
This commit adds Storybook features to the Authentik four-stage button.
The four-stage button is used to:
- trigger an action
- show that the action is running
- show when the action has succeeded, then reset
- show when the action has failed, then reset
It is used mostly for fetching data from the server. The variants are:
- ak-spinner-button: The basic form takes a single property argument, `callAction` a function that
returns a Promise (an asynchronous function).
- ak-action-button: Takes an API request function (which are all asynchronous) and adapts it to the
`callAction`. The only difference in behavior with the Spinner button is that on failure the error
message will be displayed by a notification.
- ak-token-copy-button: A specialized button that, on success, pushes the content of the retrieved
object into the clipboard.
Cleanup consisted of:
- removing a lot of the in-line code from the HTML, decluttering it and making more explicit what
the behaviors of each button type are on success and on failure.
- Replacing the ad-hoc Promise management with Lit's own `Task` handler. The `Task` handler knows
how to notify a Lit-Element of its own internal state change, making it ideal for objects like
this button that need to change their appearance as a Promise'd task progresses from idle →
running → (success or failure).
- Providing JSDoc strings for all of the properties, slots, attributes, elements, and events.
- Adding 'pointer-events: none' during the running phases of the action, to prevent the user from
clicking the button multiple times and launching multiple queries.
- Emitting an event for every stage of the operation:
- `ak-button-click` when the button is clicked.
- `ak-button-success` when the action completes. The payload is included in `Event.detail.result`
- `ak-button-failure` when the action fails. The error message is included in `Event.detail.error`
- `ak-button-reset` when the button completes a notification and goes back to idle
**Storybook**
Since the API requests for both `ak-spinner-button` and `ak-action-button` require only that a
promise be returned, Storybooking them was straightforward. `ak-token-copy-button` is a
special-purpose derivative with an internal functionality that can't be easily mocked (yet), so
there's no Storybook for it.
All of the stories provide the required asynchronous function, in this cose one that waits three
seconds before emitting either a `response` or `reject` Promise.
`ak-action-button`'s Story has event handler code so that pressing on the button will result in a
message being written to a display block under the button.
I've added a new pair of class mixins, `CustomEmitterElement` and `CustomListenerElement`. These
each add an additional method to the classes they're mixed into; one provides a very easy way to
emit a custom event and one provides a way to receive the custom event while sweeping all of the
custom event type handling under the rug.
`emitCustomEvent` replaces this:
``` JavaScript
this.dispatchEvent(
new CustomEvent('ak-button-click', {
composed: true,
bubbles: true,
detail: {
target: this,
result: "Some result, huh?"
},
})
);
```
... with this:
``` JavaScript
this.dispatchCustomEvent('ak-button-click', { result: "Some result, huh?" });
```
The `CustomListenerElement` handler just ensures that the handler being passed to it takes a
CustomEvent, and then makes sure that any actual event passed to the handler has been type-guarded
to ensure it is a custom event.
**Observations**
*Composition vs Inheritance, Part 1*
The four-state button has three implementations. All three inherit from `BaseTaskButton`:
- `spinner`
- provides a default `callAction()`
- `action`
- provides a different name for `callAction`
- overrides `onError` to display a Notification.
- `token-copy`
- provides a custom `callAction`
- overrides `onSuccess` to copy the results to the keyboard
- overrides `onError` to display a Notification, with special handling for asynchronous
processing.
The *results* of all of these could be handled higher up as event handlers, and the button could be
just a thing that displays the states. As it is, the BaseStateToken has only one reason to change
(the Promise changes its state), so I'm satisfied that this is a suitable evolution of the product,
and that it does what it says it does.
*Developer Ergonomics*
The one thing that stands out to me time and again is just how *confusing* all of the Patternfly
stuff tends to be; not because it's not logical, but because it overwhelms the human 7±2 ability to
remember details like this without any imperative to memorize all of them. I would like to get them
under control by marshalling them under a semantic CSS regime, but I'm blocked by some basic
disconnects in the current development environment. We can't shake out the CSS as much as we'd like
because there's no ESPrima equivalent for Typescript, and the smallest bundle purgeCSS is capable of
making for just *one* button is about 55KB. That's a bit too much. It's a great system for getting
off the ground, but long-term it needs more love than we (can) give it.
* Prettier has opinions.
* Removed extraneous debugging code.
* Added comments to the BaseTaskButton parent class.
* web: fixed two build errors (typing) in the stories.
* web: prettier's got opinions
* web: refactor the buttons
This commit adds URL mocking to Storybook, which in turn allows us to
commit a Story for ak-token-copy-button.
I have confirmed that the button's algorithm for writing to the
clipboard works on Safari, Chrome, and Firefox. I don't know
what's up with IE.
* ONE BYTE in .storybook/main blocked integration.
With the repair of lit-analyze, it's time to fix the rule set
to at least let us pass for the moment.
* Still looking for the list of exceptions in lit-analyze that will let us pass once more.
* web: repair error in EnterpriseLicenseForm
This commit continues to find the right configuration for
lit-analyze. During the course of this repair, I discovered
a bug in the EnterpriseLicenseForm; the original usage could
result in the _string_ `undefined` being passed back as a
value. To handle the case where the value truly is undefined,
the `ifDefined()` directive must be used in the HTML template.
I have also instituted a case-by-case stylistic decision to allow
the HTML, and only the HTML, to be longer that 100 characters
when doing so reduces the visual "noise" of a function.
|
|||
| 4e5ea05987 |
web: refactor locale handler into top-level context handler (#6022)
* web: begin refactoring the application for future development This commit: - Deletes a bit of code. - Extracts *all* of the Locale logic into a single folder, turns management of the Locale files over to Lit itself, and restricts our responsibility to setting the locale on startup and when the user changes the locale. We do this by converting a lot of internal calls into events; a request to change a locale isn't a function call, it's an event emitted asking `REQUEST_LOCALE_CHANGE`. We've even eliminated the `DETECT_LOCALE_CHANGE` event, which redrew elements with text in them, since Lit's own `@localized()` decorator does that for us automagically. - We wrap our interfaces in an `ak-locale-context` that handles the startup and listens for the `REQUEST_LOCALE_CHANGE` event. - ... and that's pretty much it. Adding `@localized()` as a default behavior to `AKElement` means no more custom localization is needed *anywhere*. * web: improve the localization experience This commit fixes the Storybook story for the localization context component, and fixes the localization initialization pass so that it is only called once per interface environment initialization. Since all our interfaces share the same environment (the Django server), this preserves functionality across all interfaces. --------- Co-authored-by: Jens Langhammer <jens@goauthentik.io> |
|||
| 44a057ed9c |
web: Replace lingui.js with lit-localize (#5761)
* \#\# Details
web: replace lingui with lit/localize
\#\# Changes
This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()`
syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced
all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`.
The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be
checked over by professional translators. The actual _strings_ have not been changed, but as this was
a mechanized change there is always the possibility of mis-translation-- not by the translator, but by
the script.
* web: revise lit/localize: fix two installation issues.
* web: revise localization
TL;DR:
- Replaced all of Lingui's `t()` syntax with `msg()` syntax.
- Mechanically (i.e with a script) converted all of the PO files to XLIFF files
- Refactored the localization code to be a bit smarter:
- the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the
first match of:
- The locale's code exactly matches the requested locale
- The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US")
- the locale code's prefix exactly matches the prefix of the requested locale
This function is passed to lit-locate's `loadLocale()`.
- `activateLocale()` just calls `loadLocale()` now.
- `autodetectLanguage` searches the following, and picks the first that returns a valid locale
object, before passing it to `loadLocale()`:
- The User's settings
- A `?locale=` component found in `window.location.search`
- The `window.navigator.language` field
- English
The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache
strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine
can look up the strings in the preferred language of the user at that moment.
You can use thunks-of-strings if you really need them that way.
* Including the 'xliff-converter' in case anyone wants to review it.
* The xliff-converter is tagged as 'xliff-converter', but has been
deleted.
\#\# Details
- Resolves #5171
\#\# Changes
\#\#\# New Features
- Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator.
\#\#\# Breaking Changes
- Adds breaking change which causes \<issue\>.
\#\# Checklist
- [ ] Local tests pass (`ak test authentik/`)
- [ ] The code has been formatted (`make lint-fix`)
If an API change has been made
- [ ] The API schema has been updated (`make gen-build`)
If changes to the frontend have been made
- [ ] The code has been formatted (`make web`)
- [ ] The translation files have been updated (`make i18n-extract`)
If applicable
- [ ] The documentation has been updated
- [ ] The documentation has been formatted (`make website`)
* web: fix redundant locales for zh suite.
* web: prettier pass for locale update
* web: localization moderization
Changed the names of the lit-localize commands to make it clear they're
part of the localization effort, and not just "build" and "extract".
* update transifex config
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix package lock?
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* use build not compile
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* web: conversion to lit-localize
The CI produced a list of problems that I hadn't caught earlier,
due to a typo ("localize build" is correct, "localize compile" is
not) I had left in package.json. They were minor and linty, but
it was still wise to fix them.
* web: replace lingui with lit/locale
This commit fixes some minor linting issues that were hidden by a typo in package.json. The
issues were not apparently problematic from a Javascript point of view, but they pointed
to sloppy thinking in the progression of types through the system, so I cleaned them
up and formalized the types from LocaleModule to AkLocale.
* web: replace lingui with lit/localize
One problem that has repeatedly come up is that localize's templates do not produce
JavaScript that conforms with our shop style. I've replaced `build-locale` with
a two-step that builds the locale *and* ensures that it conforms to the shop style
via `prettier` every time.
* web: replace lingui with lit-locale
This commit applies the most recent bundle of translations to the
new lit-locale aspect component. It also revises the algorithm
for *finding* the correct locale, replacing the complex fall-back
with some rather straightforward regular expressions.
In the case of Chinese, the fallback comes at the end of the
selection list, which may not be, er, politically valuable
(since Taiwan and Hong Kong come before, being exceptions that
need to be tested). If we need a different order for presentation,
that'll be a future feature.
* web: replace lingui with lit/locale
Well, that was embarassing.
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>
|
|||
| b6b820f6f1 | web: toggle dark/light theme manually (#4876) | |||
| 4a91a7d2e2 |
web: re-organise frontend and cleanup common code (#3572)
* fix repo in api client Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * web: re-organise files to match their interface Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * core: include version in script tags Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * cleanup maybe broken Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * revert rename Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * web: get rid of Client.ts Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * move more to common Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * more moving Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * format Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * unfuck files that vscode fucked, thanks Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * move more Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * finish moving (maybe) Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * ok more moving Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * fix more stuff that vs code destroyed Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * get rid "web" prefix for virtual package Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * fix locales Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * use custom base element Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * fix css file Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * don't run autoDetectLanguage when importing locale Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * fix circular dependencies Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * web: fix build Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> |
|||
| a8c04f96d2 | web: use absolute imports with path rewrite instead of relative imports (#3149) | |||
| 1cb71b5217 |
web: fix invalid import paths
Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> |
|||
| fd1d38f844 |
stages/authenticator_validate: remember (#2828)
* initial Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * web: cleanup timedelta help Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * add tooltip Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * add tests Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * assert response code in self.assertStageResponse Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * add more tests, add duo Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * add docs Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> * fix Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> |
|||
| 43bf9e6c21 |
web: remove common_styles
Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org> |
|||
| 68eefd083e | web: fix linting errors | |||
| f8ba623fc1 | web: add more related links, add policy/user/group support for bindings |
