* 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: description lists as functions
One thing I hate is clutter. Just tell me what you're going to do. "Description Lists" in our code are
renderings of Patternfly's DescriptionList; we use only four of
their idioms: horizontal, compact, 2col, and 3col. With that in mind, I've stripped out the DescriptionList
rendering code from UserViewPage and replaced it with a list of "Here's what to render" and a function call
to render them. The calling code is still responsible for having the right styles available, as this is
not a component or an attempt at isolation; it is *just* a function (at this point).
* web: fix issue that prevented the classMap from being rendered properly
* web: added comments to the description list.
* web: analyze & prettier had opinions
* web: Fix description-list demo
This commit re-instals the demo for the "description list" of user fields.
* web: prettier had opinions.
* any -> unknown
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>
* 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: extract the form processing from the form submission process
Our forms have a lot of customized value handling, and the function `serializeForm` takes
our input structures and creates a JSON object ready for submission across the wire for
the various models provided by the API.
That function was embedded in the `ak-form` object, but it has no actual dependencies on
the state of that object; aside from identifying the input elements, which is done at the
very start of processing, this large block of code stands alone. Separating out the
"processing the form" from "identifying the form" allows us to customize our form handling
and preserve form information on the client for transactional purposes such as our wizard.
w
* web: multi-select, but there's a styling issue.
* web: provide a closed control for multi-select
This commit creates a new control, using the ak-form-element-horizontal as a *CLOSED*
object, for our multi-select. This control right now is limited to what we expect to
be using in the wizard, but that doesn't mean it can't be smarter in the future.
* web: hung up by a silly spelling error
* web: update the form-handling method
With the `serializeForm` method extracted, it's much easier to examine and parse
every *form* with every keystroke, preserving them against the changes that
happen as the customer navigates the Wizard. With that in place, it became
straightforward to retrofit the "handle changes to the application, to the provider, and to the providerType"
into the three pages of the wizard, and to provide *all* of the form elements in a base class
such that no specialized handling needs to happen to any of the child pages.
Fixed an ugly typo in the oauth2 provider, as well.
* web: wizard should work with multi-select and should reflect default values
(Note: This commit is predicated on both the "Extract serializeForm function from Form.ts" and
"Provide a controlled multi-select input control" PRs.)
The initial attempt at the wizard was woefully naive in its implementation, missing some critical
details along the way. This revision starts off with one stronger assumption: trust that Jens knows
what he's doing, and knew what he was building when he wrote the initial `Form` handler.
The problem with the `Form` handler, and the reason I avoided it, was simply that it does too many
things, especially in its ModelForm variant: it receives a model from the back-end, renders a
(hand-written) form for that model, allows the user to interact with that model, and facilitates
saving it to the back-end again, complete with on-page notifications of success or failure.
The Wizard could not use all of that. It needs to gather the information for *two* models (an
Application and a Provider, plus the ProviderType) and has a new and specialized end-point for a
transaction that allows the committing or roll back of both models to happen simultaneously,
predicated on success or failure respectively.
With "Extract `serializeForm` completed, it was possible to repurpose the forms that already
existed, stripping them down to just their input components, and eventing the entire thing in a
single event loop of "events flow up, data flows down." In this case, the *entire form* is
serialized on a per-event basis and pushed up the to the orchestration layer, which saves them off.
Writing a parent `BasePanel` class that has accessors for `formValues` and `valid` means that the
state of every page is accessible with a simple query. This simplified the `BaseProviderPanel` class
to just specialize the `dispatchUpdate` method to send the wizard update with the new provider
information filled out.
Because the *form* is being treated as the source of truth about the state of a `Partial<Application>`
or `Partial<*Provider>` object, the defaults are now being captured as expected.
Likewise, this simplified the `providerCache` layer which preserves customer input in the event that
the customer starts filling out the wrong provider to a simple conditional clause in the
orchestrator. The Wizard has much fewer smarts because it doesn't (and probably never did) need
them.
Along with the above changes, the following has also been done:
For SAML and SCIM, the providerMappings now works. They weren't being managed as `state` objects,
so they weren't receiving updates when the update event retrieved the information from the back-end.
In order to make clear what's happening, I have extracted the loops from the original definition and
built them as named objects: `propertyMappings`, `pmUserValues`, `pmGroupValues` and so on, which I
then pass into the new multi-select component.
I fixed a really embarrassing typo in Oauth2's "advanced settings" block.
I have extracted the CoreGroup search-select into a custom component.
I deleted the `merge` function. That was a faulty experiment with non-deterministic outcomes, and I
was never happy with it. I'm glad its gone.
I've added a title header to each of the providers, so the user can be sure that they're looking
at the right provider type when they start filling out the form.
I've created a new token, `data-ak-control`, with which we can mark all objects that we can treat as
Authentik value-producing components, the form value of which is available through a `json()`
method. I've added this bit of intelligence to the `serializeForm` function, short-circuiting the
complex processing and putting the "this is the shape of the value we expect from this input" *onto
the input itself*. Which is where it belongs.
* web: add error handling to wizard.
* web: improve error handling in light components
Rather than reproduce the error handling across all of the LightComponents,
I've made a parent class that takes the common fields to distribute between
the ak-form-element-horizontal and the input object itself. This made it
much easier to properly display errors in freeform input fields in the
wizard, as well as working with the routine error handling in Form.ts
* Added the radio control to the list of LightComponents.
* Fix bug where event was recorded twice.
* Fixed merge bug (?) that somehow deleted the Authorization Select block in OAuth2.
* web: prettier had opinions
* web: added error handling and display
* web: bump @lit-labs/context from 0.4.1 to 0.5.1 in /web
Bumps [@lit-labs/context](https://github.com/lit/lit/tree/HEAD/packages/labs/context) from 0.4.1 to 0.5.1.
- [Release notes](https://github.com/lit/lit/releases)
- [Changelog](https://github.com/lit/lit/blob/main/packages/labs/context/CHANGELOG.md)
- [Commits](https://github.com/lit/lit/commits/@lit-labs/context@0.5.1/packages/labs/context)
---
updated-dependencies:
- dependency-name: "@lit-labs/context"
dependency-type: direct:production
update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>
* web: updated wizard to run with latest package.json configuration
Apparently, there were stale dependencies in package-lock.json that were conflicting
with the requests in our package.json. By running `npm update`, I was able to resolve
the conflict.
I have also removed the default names from the context names collection; they weren't doing
any good, and they permit frictionless renaming of dependencies, which is never a good
idea.
* web: schlepping on the errors messages
During testing, I realized I was unhappy with the error messages. They're not very helpful.
By adding links to navigate back to the place where the error occurred, and providing better
context for what the error could have been, I hope to help the use correct their errors.
* make package the same as main
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
---------
Signed-off-by: dependabot[bot] <support@github.com>
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>
* 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.
* A quality of life thing: `<ak-status-label good>`
There's an idiom throughout the UI:
``` HTML
<ak-label color=${item.enabled ? PFColor.Green : PFColor.Red}>
${item.enabled ? msg("Yes") : msg("No")}
</ak-label>
```
There are two problems with this.
- Repeating the conditional multiple times is error-prone
- The color scheme doesn't communicate much.
There are uses for ak-label that aren't like this, but I'm focusing on this particular use case,
which occurs about 20 times throughout the UI.
Since it's so common, let's isolate the most common case: `<ak-status-label good />` gives you the
"good" status, and `<ak-status-label/>` gives you the "bad" status, which is the default (no
arguments to the function).
There wasn't much clarity in the system for when to use orange vs red vs grey, but looking through
the use cases, it became clear that Red meant fail/inaccessible, Orange meant "Warning, but not
blocking," and Grey just means "info: this thing is off".
So let's define that with meaning: there are three types, error, warning, and info. Which
corresponds to debugging levels, but whatever, nerds grok that stuff.
So that example at the top becomes
```<ak-status-label ?good=${item.enabled}></ak-status-label>```
... and we can now more clearly understand what that conveys.
There is some heavy tension in this case: this is an easier and quicker-to-write solution to
informing the user of a binary status in an iconic way, but the developer has to remember that it
exists.
Story provided, and changes to the existing uses of the existing idiom provided.
* Added the 'compact label' story to storybook.
The old comment was left over from a previous revision of the wizard, and
blocked lit-analyze's ability to understand the Modal's `slot="trigger"`
declaration.
* A lot of comments about forms.
* Adding comments to the wizard.
* Broke out the text input into a single renderer. Still works as required.
* web: Legibility in the ApplicationForm.
This is a pretty good result. By using the LightDOM setting, this
provides the existing Authentik form manager with access to the
ak-form-horizontal-element components without having to do any
cross-border magic. It's not ideal, and it shows up just how badly
we've got patternfly splattered everywhere, but the actual results
are remarkable. The patterns for text, switch, radio, textarea,
file, and even select are smaller and easier here.
I'm still noodling on what an unspread search-select element would
look like. It's just dependency injection, so it ought to be as
straightforward as that.
* web: Marking down the start of the 'components' library.
* web: Baby steps
I become frustrated with my inability to make any progress on this project, so I decided to reach
for a tool that I consider highly reliable but also incredibly time-consuming and boring: test
driven development.
In this case, I wrote a story about how I wanted to see the first page rendered: just put the HTML
tag, completely unadorned, that will handle the first page of the wizard. Then, add an event handler
that will send the updated content to some parent object, since what we really want is to
orchestrate the state of the user's input with a centralized location. Then, rather than fiddling
with the attributes and properties of the various pages, I wanted them to be able to "look up" the
values they want, much as we'd expect a standalone form to be able to pull its values from the
server, so I added a context object that receives the update event and incorporates the new
knowledge about the state of the process into itself.
The result is surprisingly satisfying: the first page renders cleanly, displays the content that we
want, and as we fiddle with, we can *watch in real time* as the results of the context are updated
and retransmitted to all receiving objects. And the sending object gets the results so it
re-renders, but it ends up looking the same as it was before the render.
* Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug:
the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend
their events as standard `input` events, and that actually seems to work well; the browser is
decorating it with the right target, with the right `name` attribute, and since we have good
definitions of the `value` as a string (the real value of any search object is its UUID4), that
works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs),
and the latter has flags for "use the first one if it's the only one" and "allow the display of
keyless certificates."
Not sure why `state()` is blocking the transmission of typing information from the typed element
to the context handler, but it's a bug in the typechecker, and it's not a problem so far.
* Now, it's starting to look like a complete package. The LDAP method is working, but there is a bug:
the radio is sending the wrong value !?!?!?. Track that down, dammit. The search wrappers now resend
their events as standard `input` events, and that actually seems to work well; the browser is
decorating it with the right target, with the right `name` attribute, and since we have good
definitions of the `value` as a string (the real value of any search object is its UUID4), that
works quite well. Added search wrappers for CoreGroup and CryptoCertificate (CertificateKeyPairs),
and the latter has flags for "use the first one if it's the only one" and "allow the display of
keyless certificates."
Not sure why `state()` is blocking the transmission of typing information from the typed element
to the context handler, but it's a bug in the typechecker, and it's not a problem so far.
* web: tracked down that weirld bug with the radio.
Because radio inputs are actually multiples, the events handling for
radio is... wonky. If we want our `<ak-radio>` component to be a
unitary event dispatcher, saying "This is the element selected," we
needed to do more than what was currently being handled.
I've intercepted the events that we care about and have placed
them into a controller that dictates both the setting and the
re-render of the component. This makes it "controlled" (to use the
Angular/React/Vue) language and depends on Lit's reactiveElement
lifecycle to work, rather than trust the browser, but the browser's
experience with respect to the `<input type=radio` is pretty bad:
both input elements fire events, one for "losing selection" and
one for "gaining selection". That can be very confusing to handle,
so we funnel them down in our aggregate radio element to a single
event, "selection changed".
As a quality-of-life measure, I've also set the label to be
unselectable; this means that a click on the label will trigger the
selection event, and a long click will not disable selection or
confuse the selection event generator.
* web: now passing the precommit phase
* web: a HACK for Storybook to inject the "use light theme" flag into the body.
This isn't really a very good hack; what it does is say that every story is
responsible for hacking its theme into the parent. This is very annoying, but
it does mean that we can at least show our components in the best light.
* web: ak-application-wizard-authentication-by-oauth, and many fixes!
1. Fixed `eventEmitter` so that if the detail object is a scalar, it will not attempt to "objectify"
it. This was causing a bug where retrofitting the eventEmitter to some older components resulted
in a detail of "some" being translated into ['s', 'o', 'm', 'e']. Not what is wanted.
2. Removed the "transitional form" from the existing components; they had a two-step where the web
component class was just a wrapper around an independent rendering function. While this worked,
it was only to make the case that they *were* independent rendering objects and could be
supported with the right web component framework. We're halfway there now; the last step will be
to transform the horizontal-element and various input CSS into componentized CSS, the way
Patternfly-Elements is currently doing.
3. Fixed the `help` field so that it could take a string or a TemplateResult, and if the latter,
don't bother wrapping it in the helper text functionality; just let it be its own thing. This
supports the multi-line help of redirectURI as well as the `ak-utils-time-delta` capability.
4. Transform Oauth2ProviderForm to use the new components, to the best of our ability. Also used
the `provider = this.wizard.provider` and `provider = this.instance` syntax to make the render
function *completely portable*; it's the exact same text that is dropped into...
5. The complete `ak-application-wizard-authentication-by-oauth` component. They're so similar part
of me wonders if I could push them both out to a common reference, or a collection of common
references. Both components use the PropertyMapping and Sources, and both use the same
collection of searches (Crypto, Flow).
6. A Storybook for `ak-application-wizard-authentication-by-oauth`, showing the works working.
7. New mocks for `authorizationFlow`, `propertyMappings`, and `hasJWKs`.
This sequence has revealed a bug in the radio control. (It's always the radio control.) If the
default doesn't match the current setting, the radio control doesn't behave as expected; it won't
change when you fully expect that it should. I'll investigate how to harmonize those tomorrow.
* web: Converted our toggle groups to a more streamlined implementation.
* web: one more toggle group.
* initial api and schema
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* separate blueprint importer from yaml parsing
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* cleanup
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* web: Replace ad-hoc toggle control with ak-toggle-group
This commit replaces various ad-hoc implementations of the Patternfly Toggle Group HTML with a web
component that encapsulates all of the needed behavior and exposes a single API with a single event
handler, return the value of the option clicked.
The results are: Lots of visual clutter is eliminated. A single link of:
```
<div class="pf-c-toggle-group__item">
<button
class="pf-c-toggle-group__button ${this.mode === ProxyMode.Proxy
? "pf-m-selected"
: ""}"
type="button"
@click=${() => {
this.mode = ProxyMode.Proxy;
}}>
<span class="pf-c-toggle-group__text">${msg("Proxy")}</span>
</button>
</div>
<div class="pf-c-divider pf-m-vertical" role="separator"></div>
```
Now looks like:
```
<option value=${ProxyMode.Proxy}>${msg("Proxy")}</option>
```
This also means that the three pages that used the Patternfly Toggle Group could eliminate all of
their Patternfly PFToggleGroup needs, as well as the `justify-content: center` extension, which also
eliminated the `css` import.
The savings aren't as spectacular as I'd hoped: removed 178 lines, but added 123; total savings 55
lines of code. I still count this a win: we need never write another toggle component again, and
any bugs, extensions or features we may want to add can be centralized or forked without risking the
whole edifice.
* web: minor code formatting issue.
* add new "must_created" state to blueprints to prevent overwriting objects
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* web: adding a storybook for the ak-toggle-group component
* Bugs found by CI/CD.
* web: Replace ad-hoc search for CryptoCertificateKeyPairs with ak-crypto-certeficate-search
This commit replaces various ad-hoc implementations of `search-select` for CryptoCertificateKeyPairs
with a web component that encapsulates all of the needed behavior and exposes a single API.
The results are: Lots of visual clutter is eliminated. A single search of:
```HTML
<ak-search-select
.fetchObjects=${async (query?: string): Promise<CertificateKeyPair[]> => {
const args: CryptoCertificatekeypairsListRequest = {
ordering: "name",
hasKey: true,
includeDetails: false,
};
if (query !== undefined) {
args.search = query;
}
const certificates = await new CryptoApi(
DEFAULT_CONFIG,
).cryptoCertificatekeypairsList(args);
return certificates.results;
}}
.renderElement=${(item: CertificateKeyPair): string => {
return item.name;
}}
.value=${(item: CertificateKeyPair | undefined): string | undefined => {
return item?.pk;
}}
.selected=${(item: CertificateKeyPair): boolean => {
return this.instance?.tlsVerification === item.pk;
}}
?blankable=${true}
>
</ak-search-select>
```
Now looks like:
```HTML
<ak-crypto-certificate-search certificate=${this.instance?.tlsVerification}>
</ak-crypto-certificate-search>
```
There are three searches that do not require there to be a valid key with the certificate; these are
supported with the boolean property `nokey`; likewise, there is one search (in SAMLProviderForm)
that states that if there is no current certificate in the SAMLProvider and only one certificate can
be found in the Authentik database, use that one; this is supported with the boolean property
`singleton`.
These changes replace 382 lines of object-oriented invocations with 36 lines of declarative
configuration, and 98 lines for the class. Overall, the code for "find a crypto certificate" has
been reduced by 46%.
Suggestions for a better word than `singleton` are welcome!
* web: display tests for CryptoCertificateKeypair search
This adds a Storybook for the CryptoCertificateKeypair search, including
a mock fetch of the data. In the course of running the tests, we discovered
that including the SearchSelect _class_ won't include the customElement declaration
unless you include the whole file! Other bugs found: including the CSS from
Storybook is different from that of LitElement native, so much so that the
adapter needed to be included. FlowSearch had a similar bug. The problem
only manifests when building via Webpack (which Storybook uses) and not
Rollup, but we should support both in distribution.
* Fixed behavioral problem with the radio; the `if` there was
preventing the radio from reflecting the default correctly.
The observed behavior was that the radio wouldn't "activate"
until the item selected during the render pass was clicked on
first.
* Proxy Provider done.
* web: Tactical change. Put all the variants on the second page; it's
a longer list, but it's also easier to manage than all those
required sub-options.
* Rounding out the catalog.
* web: SAML Manual Configuration
Added a 'design document' that just kinda describes what I'm trying
to do, in case I don't get this done by Friday Aug 11, 2023.
I had two tables doing the same thing, so I merged them and then
wrote a few map/filters to specialize them for those two use cases.
Along the way I had to fiddle with the ESLint settings so that
underscore-prefixed unused variables would be ignored.
I cleaned up the visual appeal of the forms in the LDAP application.
I was copy/pasting the "handleProviderEvent" function, so I pulled
it out into ApplicationWizardProviderPageBase. Not so much a matter
of abstraction as just disliking that kind of duplication; it served
no purpose.
* Added SAML Story to Storybook.
* Web: This is coming together amazingly well. Like, almost too well.
* web: 80% of the way there
This commit includes the first three pages of the wizard, the
completion of the wizard framework with evented handling, and control
over progression.
Some shortcomings of this design have become evident: it isn't
possible to communicate between the steps' wrappers, as they are
POJOs without access to the context. An imperative decision-making
process has to be inserted in the orchestration layer,
which is kinda annoying.
But it looks good and it behaves correctly, to the extent that I've
given it behavior. It's an excellent foundation.
* Linting.
* web: application wizard
Found where the hook for form validity should go. Excellent! Now I just need to incorporate
that basic validation into the business logic and we're good to go.
* Turns out that was one layer too many; the topmost component was fine for
maintaining the context.
* It looks like my brilliant strategy has hit a snag.
The idea is simple. Let's start with this picture:
```
<application-wizard .steps=${[... a collection of step objects ...]}>
<wizard-main .steps=${(steps from above)}>
<application-current-panel>
<current-form>
```
- ApplicationWizard has a Context for the ApplicationProviderPair (or whatever it's going to be).
This context does not know about the steps; it just knows about: the "application" object, the
"provider" object, and a discriminator to know *which* provider the user has selected.
- ApplicationWizard has Steps that, among other things, provides Panels for:
- Application
- Pick Provider
- Configure Provider
- Submit ApplicationProviderPair to the back-end
- The WizardFrame renders the CurrentPanel for the CurrentStep
The CurrentPanel gets its data from the ApplicationWizard in the form of a Context. It then sends
messages (events) to ApplicationWizard about the contents of each field as the user is filling out
the form, so that the ApplicationWizard can record those in the ApplicationProviderPair for later
submission.
When a CurrentForm is valid, the ApplicationWizard updates the Steps object to show that the "Next
button" on the Wizard is now available.
In this way, the user can progress through the system. When they get to the last page, we can
provide in the ApplicationWizard with the means to submit the form and/or send the user back to
the page with the validation failure.
Problem: The context is being updated in real-time, which is triggering re-renders of the form. This
leads to focus problems as the fields that are not yet valid are triggering "focus grab" behavior.
This is a classic problem with "controlled" inputs. What we really want is for the CurrentPanel to
not re-render at all, but to behave like a normal, uncontrolled form, and let the browser do most of
the work. We still want the [Next] button to enable when the form is valid enough to permit that.
---
Other details: I've ripped out a lot of Jen's work, which is probably a mistake. It's still
preserved elsewhere. I've also cleaned up the various wizardly things to try and look organized.
It *looks* like it should work, it just... doesn't. Not yet.
* Late addition: I had an inspiration about how to reduce the way
reactivity broke focus by, basically, removing the reactivity and
managing the first-time-through lifecycle to prevent the update
from causing refocus. It works well! Now I just need to test it.
* This application fixes the bug with respect to the wizard-level context being updated incorrectly.
Understandings:
- To use uncontrolled inputs, which I prefer, the context object should not be a state or property
at the level of consumers; it should not automatically re-render with every keystroke, i.e. "The
React Way." We're using Web Components, [client-side
validation](https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation) exists on the
platform already, and live-validation is problematic for any number of reasons.
- The trade-off is that it is now necessary to re-render the target page of the wizard de-novo, but
that's not really as big a deal as it sounds. Lit is ready to do that... and then nothing else
until we request a change-of-page. Excellent.
- The top level context *must* be a state, but it's better if it's a state never actually used by
the top-level context container. The debate about whether or not to make that container a dumb one
(`<slot></slot>`) or to merge it with the top-level object continues; here, I've merged it with
the top-level wizard object, but that object does not refer to the state variable being managed in
its render pass, so changes to it do not cause a re-render of the whole wizard. The purpose of the
top-level page is to manage the *steps*, not the *content of any step*. A step may change
dynamically based on the content of a step, but that's the same thing as *which step*. Lesson:
always know what your state is *about*.
- Deep merging is a complex subject, but here it's appropriate to our needs.
* web: Application Wizard
This commit combines a working (but very unpolished) version of the Application Wizard with Jen's
code for the CoreTransactionApplicationRequest, resulting in a successful round trip.
It fixes a number of bugs with the way ContextProducer decorators were being processed, such that
they just weren't working with our current configuration (although they did work fine in Storybook);
consumers didn't need to be fixed.
It also *removes* the steps-aware context from the Wizard.
That *may* be a mistake. To re-iterate, the `WizardFrame` provides the chrome for a Wizard: the
button bar div, the breadcrumbs div, the header div, and it takes the steps object as its source of
truth for all of the content. The `WizardContent` part of the application has two parts: The
`WizardMain`, which wraps the frame and supplies the context for all the `WizardPanels`, and the
`WizardPanels` themselves, which are dependent on a context from `WizardMain` for the data that
populates each panel. YAGNI right now that the panels need to know anything about the steps, and the
`WizardMain` can just pass a fresh `.steps` object to the `WizardFrame` when they need updating.
Using props drilling may make more sense here.
It certainy does *not* make sense for the panels. They need to be renderable on-demand, and they
need to make sense of what they're rendering on-demand, so the function is
```
(panel code) => (context) => (rendered panel)
```
(Yes, that's curried notation. Deal.)
* This commit includes the first WDIO test for the ApplicationWizard. It doesn't do much right now, but
it does log in and navigate to the wizard successfully.
* web: completed test for single application, provided new programming language to make it easier to write tests.
* Almost there.
Missing: The validation is currently not working as expected, and I cannot get the backend
to give me meaningful data helping us "go back" to the field that wasn't valid. I really
don't want to put all the meaningful validation on the front-end; that's the road to -
perdition, the back-end must be usable by people less assiduous than we are.
Also: Need to make the button bar work better; maybe each panel can provide a custom button
bar if one is needed?
* web: Test harness
We have an end-to-end test harness that includes a trivially correct DSL for "This is what a user would do, do this":
```
const deleteProvider = (theSlug) => ([
["button", '>>>ak-sidebar-item a[href="#/core/providers"]'],
["deletebox", `>>>a[href="#/core/applications/${theSlug}"]`],
["button", '>>>ak-forms-delete-bulk button[slot="trigger"]'],
["button", '>>>ak-forms-delete-bulk div[role="dialog"] ak-spinner-button'],
]);
```
It's now possible to target individual sequences of events this way. With a little creativity, we could have standalone functions that take parameters for our calls and just do them, without too much struggle.
* web: Revised navigation
After working with the navigation for awhile, I realized that it's a poor map; what I really wanted was
a controller/view pair, where events flow up to the controller and then messages on "what to draw" flow
down to the view. It work quite well, and the wizard frame is smaller and smarter for it.
I've also moved the WDIO-driven tests into the 'tests' folder, because it (a) makes more sense to put
them there, and (b) it prevents any confusion about who's in charge of node_modules.
* web: Simplify, simplify, simplify
Sort-of.
This commit changes the way the "wizard step coordinator" layer works, giving the
wizard writer much more power over button bar. It still assumes there are only
three actions the wizard frame wants to commit: next, back, and close. This empowers
the steps themselves to re-arrange their buttons and describe the rules through which
transitions occur.
* web: resetting the form is not working yet...
I vehemently dislike the object-oriented "reset" command; every wizard should start with
an absolutely fresh copy of the data upon entry. Refactoring the wizard to re-build its
content from the inside is the correct way to go, but I don't have a good mental image
of how to make the ModalButton and the component it invokes interact cleanly, which
frustrates the hell out of me.
* web: reset
As I said, I greatly dislike having to be dependent upon "resets"; I prefer my
data to be de novo going into a "new" transaction. That said, we work with
what we've got; I've created an event generated by the wizard that says the
modal just closed; anything wrapping and implementing the wizard can then
capture that event and reset the data. I've also added a pair of functions
that create the two states (what step, what form data) anew, so that resetting
is as trivial as initializing (and is exactly the same, code-wise).
* web: Without error handling, this is complete, but I still need @BeryJu (Jens)
for help with the SAML Upload (it doesn't appear to be correctly handled?) and
the error handling.
* web: revise tests for wizard
This commit replaces the previous WDIO instance with a more formal and straightforward process using
the [pageobjects](https://martinfowler.com/bliki/PageObject.html). In this form, every major
component has its own test suite, and a test is a sequence of exercises of those components.
A test then becomes something as straightforward as:
```
await LoginPage.open();
await LoginPage.login("ken@goauthentik.io", "eat10bugs");
expect(await UserLibraryPage.pageHeader).toHaveText("My Applications");
await UserLibraryPage.goToAdmin();
expect(await AdminOverviewPage.pageHeader).toHaveText("Welcome, ");
await AdminOverviewPage.openApplicationsListPage();
expect(await ApplicationsListPage.pageHeader).toHaveText("Applications");
ApplicationsListPage.startCreateApplicationWizard();
await ApplicationWizard.app.name.setValue(`Test application ${newId}`);
await ApplicationWizard.nextButton.click();
await (await ApplicationWizard.getProviderType("ldapprovider")).click();
await ApplicationWizard.nextButton.click();
await ApplicationWizard.ldap.setBindFlow("default-authentication-flow");
await ApplicationWizard.nextButton.click();
await expect(await ApplicationWizard.commitMessage).toHaveText(
"Your application has been saved"
);
```
Whether or not there's another layer of DSL in there or not, this is a pretty nice idiom for
maintaining tests.
* web: updating with forms and fixes for eslint complaints.
* web/add webdriverIO testing layer
This commit adds WebdriverIO as an end-to-end solution to unit testing. WebdriverIO can be run both
locally and remotely, supports strong integration with web components, and is generally robust for
use in pipelines. I'll confess to working through a tutorial on how to do this for web components,
and this is just chapter 2 (I think there are 5 or so chapters...).
There's a makefile, with help! If you just run `make` it tells you:
```
Specify a command. The choices are:
help Show this help
node_modules Runs `npm install` to prepare this feature
precommit Run the precommit: spell check all comments, eslint with sonarJS, prettier-write
test-good-login Test that we can log into the server. Requires a running instance of the server.
test-bad-login Test that bad usernames and passwords create appropriate error messages
```
... because Makefiles are documentation, and documentation belongs in Makefiles.
I've chosen to go with a PageObject-oriented low-level DSL; what that means is that for each major
components (a page, a form, a wizard), there's a class that provides human-readable names for
human-interactable and human-viewable objects on the page. The LoginPage object, for example, has
selectors for the username, password, submit button, and the failure alert; accessing those allows
us to test for items as expected., and to write a DSL for "a good login" that's as straightforward
as:
```
await LoginPage.open();
await LoginPage.login("ken@goauthentik.io", "eat10bugs");
await expect(UserLibraryPage.pageHeader).toHaveText("My applications");
```
There was a *lot* of messing around with the LoginPage to get the username and password into the
system. For example, I had to do this with all the `waitForClickable` and `waitForEnable` because
we both keep the buttons inaccessible until the form has something and we "black out" the page (put
a darkening filter over it) while accessing the flow, meaning there was a race condition such that
the test would attempt to interact with the username or password field before it was accessible.
But this works now, which is very nice.
``` JavaScript
get inputUsername() {
return $('>>>input[name="uidField"]');
}
get btnSubmit() {
return $('>>>button[type="submit"]');
}
async username(username: string) {
await this.inputUsername.waitForClickable();
await this.inputUsername.setValue(username);
await this.btnSubmit.waitForEnabled();
await this.btnSubmit.click();
}
```
The bells & whistles of *Prettier*, *Eslint*, and *Codespell* have also been enabled. I do like my
guardrails.
* web/adding tests: added comments and cleaned up some administrative features.
* web/test: changed the name of one test to reflect it's 'good' status
* core/allow alternative postgres credentials
This commit allows the `dev-reset` command in the Makefile to pick up and use credentials from the
`.env` file if they are present, or fallback to the defaults provided if they are not. This is the
only place in the Makefile where the database credentials are used directly against postgresql
binaries. The syntax was tested with bash, zsh, and csh, and did not fail under those.
The `$${:-}` syntax is a combination of a Makefile idiom for "Pass a single `$` to the environment
where this command will be executed," and the shell expresion `${VARIABLE:-default}` means
"dereference the environment variable; if it is undefined, used the default value provided."
* Re-arrange sequence to avoid recursive make.
Nothing wrong with recursive make; it just wasn't essential
here. `migrate` is just a build target, not a task.
* Cleanup according to the Usage:
checkmake [options] <makefile>...
checkmake -h | --help
checkmake --version
checkmake --list-rules Makefile linting tool.
* core: added 'help' to the Makefile
* get postgres config from authentik config loader
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* don't set -x by default
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* sort help
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* update help strings
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* web: test LDAP wizard sequence
* web: improve testing by adding test admin user via blueprint
* This commit continues the application wizard buildout. In this commit are the following changes:
- Added SCIM to the list of available providers
- Fixed ForwardProxy so that its mode is set correctly. (This is a special case in the committer;
I'm unhappy with that.)
- Fixed the commit messages so that:
- icons are set correctly (Success, Danger, Working)
- icons are colored correctly according to state
- commit message includes a `data-commit-state` field so tests can find it!
- Merged the application wizard tests into a single test pass
- Isolated common parts of the application wizard tests to reduce unnecessary repetition. All
application tests are the same until you reach the provider section anyway.
- Fixed the unit tests so they're finding the right error messages and are enabled to display them
correctly.
- Moved the test Form handlers into their own folder so they're not cluttering up the Pages folder.
* web: add radius to application wizard
This commit continues the application wizard buildout. In this commit are the following changes:
- Fixed a width-setting bug in the Makefile `make help` feature (i.e "automate that stuff!")
- Added Radius to the list of providers we can offer via the wizard
- Added `launchUrl` and `UI Settings` to features of the application page the wizard can find
- Changed 'SAML Manual Configuration' to just say "SAML Configuration"
- Modified `ak-form-group` to take and honor the `aria-label` property (which in turn makes it
easier to target specific forms with unit testing)
- Reduced the log level for wdio to 'warn'; 'info' was super-spammy and not helpful. It can be put
back with `--logLevel info` from the command line.
* fix blueprints
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* update package name
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* add dependabot
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* prettier run
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* add basic CI
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* remove hooks
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* web: application wizard refactor & completion
This commit refactors the various components of the Wizard and ApplicationWizard, creating a much
more maintainable and satisfying Wizard experience for both developers (i.e, *me* and *Jens* so
far), and for the customer.
The Wizard base has been refactored into three components:
**AkWizardController**
The `AkWizardController` provides the event listenters for the wizard; it hooks them up, recevies the
events, and forwards them to the wizard. It unwraps the event objects and forwards the relevant
messages contained in the events. It knows of three event categories:
- Navigation requests (move to a different step)
- Update requests (the current step has updated the business content)
- Close requests (close or cancel the wizard).
**ak-wizard-frame**
The `ak-wizard-frame` is the ModalButton interface. It provides the Header, Breadcrumbs (nee`
"navigation block"), Buttons, and a DIV into which the main content is rendered.
**AkWizard**
`AkWizard` is an *incomplete* implementation of the wizard. It's meant to be inherited by a child
class, which will implement the rest. It extends `AKElement`. It provides the basic content needed,
such as steps, currentStep (as an index), an accessor for the step itself, an accessor for the
frame, and the interface to the `AkWizardController`.
**ApplicationWizard**
The `ApplicationWizard` itself has been refactored to accommodate these changes. It inherits from
`AkWizard` and provides the business logic for what to do when a form updates, some custom logic for
preventing moving through the wizard when the forms are incomplete, and a persistence layer for
filling out different providers in the same session. It's simplified a *lot*.
The types specified for `AkWizard` are pretty nifty, I think. I could wish the types being passed
via the custom events were more robust, but [strongly typed custom
events](https://github.com/lit/lit-element/issues/808) turn out to be quite the pain in the, er,
neck. As it is, the `precommit` pass did very good at preventing the worst disasters.
The steps themselves were re-written as objects so that they could take advantage of their `valid`
and `disabled` states and provide more meaningful buttons and labels. I think it's a solid
compromise, and it moved a lot of display logic out of the core `handleUpdate()` business method.
The tests, such as they are, are passing.
* Added comment describing new test.
* web: ensuring copy from `main` is canon
* web: fixes after merge
* 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: eslint & prettier fixes, plus small aesthetic differences.
* Restoring this file. Not sure where it disappears to.
* fix label in dark mode
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* SCIM Manuel -> SCIM
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix lint errors
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* web: better converter configuration, CSS repair, and forward-domain-proxy
1. Forward Domain Proxy. I wasn't sure if this method was appropriate for the wizard,
but Jens says it is. I've added it.
2. In the process of doing so, I decided that the Provider.converter field was overly
complexified; I tried too hard to reduce the number of functions I needed to define,
but in the process outsourced some of the logic of converting the Wizard's dataset
into a property typed request to the `commit` phase, which was inappropriate. All
of the logic about a provider, aside from its display, should be here with the code
that distinguishes between providers. This commit makes it so.
3. Small CSS fix: the fields inherited from the Proxy provider forms had some unexpected
CSS which was causing a bit of a weird indent. That has been rectified.
* web: running pre-commit after merge.
* web: ensure the applications wizard tests finish after current changes
* prettier has opinions.
* web: application wizard spit & polish
The "ApplicationWizardHint" now correctly uses the localstorage and allows the user to navigate back
and see the message after it's been hidden, so that it will always be available during the test
phase.
The ApplicationList's old "Create Application Form" button has been restored for the purposes of the
test phase.
The ApplicationWizard is now available on both the ApplicationList and ProviderList pages.
Tana and I discussed the microcopy, putting a stronger second-person "You can do..." twist onto the
language, to give the user the sense of empowerment.
The ShowHintController now has both "hide" and "show" operations, to support the hint restoration.
* web: updated storybook stories for the wizard, illustration how "a simple wizard" is configured in source code and tested with storybook.
* web: I hate getting spanked by prettier.
* web: sometimes I wish I had lower standards
Anyway, this was a very stupid bug, because by definition function
definition arguments don't have uses, they're being defined, not
implemented. Fixed, conf fixed to compensate, and consequences
conquered.
* move context from labs to main
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* Revert "move context from labs to main"
This reverts commit 3718ee6904.
* web: reify the data loop
I was very unhappy with the "update this dot-path" mechanism I was using earlier; it was hard
for me to read and understand what was happening, and I wrote the darned thing. I decided instead
to go with a hard substitution model; each phase of the wizard is responsible for updating the
*entire* payload, mostly by creating a new payload and substituting the field value associated
with the event.
On the receiver, we have to do that *again* to handle the swapping of providers when the user
chooses one and then another. It looks clunky, and it is, but it's *legible*; a junior dev
could understand what it's doing, and that's the goal.
* Revert "web: reify the data loop"
This reverts commit 09fedcacf0.
* web: revert the 'lit' to 'lit-labs' for task and context.
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>
* web: patternfly hints as ak-web-component
Patternfly 5's "Hints" React Component, but ported to web components.
The discovery that CSS Custom Properties are still available in
child components, even if they're within independent ShadowDOMs,
made this fairly easy to port from Handlebars to Lit-HTML. Moving
the definitions into `:host` and the applications into the root DIV
of the component made duplicating the Patternfly 5 structure
straightforward.
Despite the [Patternfly
Elements]documentation](https://patternflyelements.org/docs/develop/create/),
there's a lot to Patternfly Elements that isn't well documented,
such as their slot controller, which near as I can tell just makes
it easy to determine if a slot with the given name is actually being
used by the client code, but it's hard to tell why, other than that it
provides an easy way to determine if some CSS should be included.
* Pre-commit fixes.
* web: fix some issues with styling found while testing.
* web: separated the "with Title" and "without Title" stories.
* Added footer story, fixed some CSS.
* web: hint controller
Add the `ShowHintController`. This ReactiveController takes a token
in its constructor, and looks in LocalStorage for that token and
an associated value. If that value is not `undefined`, it sets the
field `this.host.showHint` to the value found.
It also provides a `render()` method that provides an `ak-hint-footer`
with a checkbox and the "Don't show this message again," and responds
to clicks on the checkbox by setting the `this.hint.showHint` and
LocalStorage values to "false".
An example web component using it has been supplied.
* web: support dark mode for hints.
This was nifty. Still not entirely sure about the `theme="dark"`
rippling through the product, but in this case it works quite well.
All it took was defining the alternative dark mode values in a CSS
entry, `:host([theme="dark"]) { ... }` and exploiting Patternfly's
already intensely atomized CSS Custom Properties properly.
* web: revise colors to use more of the Authentik dark-mode style.
* Update web/src/components/ak-hint/ak-hint.ts
Signed-off-by: Jens L. <jens@beryju.org>
* remove any
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
---------
Signed-off-by: Jens L. <jens@beryju.org>
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Jens L <jens@goauthentik.io>
* 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>
* Web: Detangling some circular dependencies in Admin and User
Admin, User, and Flow should not dependend upon each other, at least
not in a circular way. If Admin and User depend on Flow, that's
fine, but Flow should not correspondingly depend upon elements of
either; if they have something in common, let's put them in
`@goauthentik/common` or find some other smart place to store them.
This commit refactors the intentToLabel and actionToLabel functions
into `@goauthentik/common/labels` and converts them to static tables
for maintenance purposes.
* web: "Consistency is the hobgoblin of small minds" - Ralph Waldo Emerson
* web: I found these confusing to look at, so I added comments.
* web: remove admin-to-user component reference(s)
There was only one: AppIcon. This has been moved to `components`.
Touching the LibraryApplications page triggered a cyclomatic
complexity check. Extracting the expansion block and streamlining
the class and style declarations with lit directives helped.
* web: remove admin from elements
This commit removes the two references from `elements` to `admin`: the list of UserEvents and a
reference to the FlowSearch type, used by the Forms manager to decide how to extract a value.
For FlowSearch, a different convention for detecting the type was implemented (instances of the
object have a unique fieldname for the value holder). UserEvents and ObjectChangelog have been
moved to `components` as they're clearly dependent upon the API.
This defers work on removing Admin from Components, as that is (again) references going the
wrong way, but that can happen later.
* web: remove admin-to-user component reference(s) (#6856)
There was only one: AppIcon. This has been moved to `components`.
Touching the LibraryApplications page triggered a cyclomatic
complexity check. Extracting the expansion block and streamlining
the class and style declarations with lit directives helped.
* This was supposed to be merged.
* web: remove `./element`⇢`./user` references
The offender here is UserDevicesList, which despite being in `elements` is only
used by the admin/user/UserViewPage. The problem is that UserDevicesList,
despite being in `admin`, inherits from `user`, so moving it would have created
a new admin⇢user reference, and the whole point of this exercise is to get rid
of references that point "up" from the foundational pieces to the views, or
that refer to components in sibling applications.
After examining UserDevicesList, I realized that *every feature* of MFADevicesList
had been overridden: the rows, the columns, the toolbar, and the endpoint all had
custom overrides. Nothing was left of MFADevicesList after that. Even the
property that the web component used had been completely changed. The only thing
they had in common was that they both inherited from `Table<Device>`.
Refactoring UserDevicesList so that it inherited directly from `Table<Device>` and
then moving it into `./admin/users` was the obvious and correct step.
Both used the same label table, so that went into the `common/labels` folder.
Along the way, I cleaned up a few minor details. Just little things, like the repeated invocation
of:
```
new AuthenticatorsApi(DEFAULT_CONFIG).authenticatorAdminMETHODDestroy({ id: device.pk });
```
This is repeated five times, once for each Method. By creating these:
```
const api = new AuthenticatorsApi(DEFAULT_CONFIG);
const id = { id: device.pk };
```
The method invocation could be just `api.authenticatorsMETHODDestroy(id)`, which is easier on the
eyes. See the MFADevicesPage for the full example.
Similarly,
```
return [
new TableColumn(msg("Name"), ""),
new TableColumn(msg("Type"), ""),
new TableColumn("")
];
```
is more straightforward as:
```
const headers = [msg("Name"), msg("Type"), ""];
return headers.map((th) => new TableColumn(th, ""));
```
We've labeled what we're working with, and web developers ought to know that `th` is the HTML code
for `table header`.
I've had to alter what files are scanned in pre-commit mode; it doesn't handle renamed files very well,
and at the moment a file that is renamed is not scanned, as its "new" name is not straightforwardly
displayed, not even by `git porcelain`.
* web: make the table of column headers look like a table
* web: detangle `common` from `elements`.
And just like that, `common` no longer has a reference to `elements`. I don't mind this little bit of
code duplication if it removes a cycle. What it does point out is that there are bits of `common` that
are predicated on the presence of the browser, and that there are bits of `elements` that, if they rely
on `common`, can't be disentangled from the application as a whole. Which seems to me that we have two
different things going on in common: things about an application, and things about elements that are
independent of the application.
I'll think about those later.
```
$ rg 'import.*@goauthentik' ./common/ | perl -ne 'm{"(@goauthentik[^"]*)"} && print "$1\n"' | sort | cut -d '/' -f1-2 | uniq | sort
@goauthentik/api
@goauthentik/common
$
```
* web: odd bug; merge-related? Gonna investigate.
* web: build failure thanks to local cache; fixed
* web: detangle `components` from `admin`.
This was the last inappropriate reference: something from `./components` referencing something in
`./admin`, in this case the `ak-event-info` component. Used by both Users and Admin, moving it
into `./components` was the obvious correct step.
`ak-event-info` is a lookup table relating specific events in the event log to rich, textual
representations; in the special case of model changes and email info, even more rich content is
available in a dl/dt format. I've tableized the model changes and email info renderer, and I've
extracted every event's textual representation into its own method, converting the `switch/case`
rendering statement into a `switch/case` dispatch switch. This has the virtue of isolating each
unique case and making the dispatch switch short and coherent.
The conversion was done mechanistically; I gave the refactorer (Tide, in this case) instructions to
duplicate the switch block and then convert every case into a method with a name patterned on the
`case`. Going back to the original switch block, it was easy to duplicate the pattern matching and
convert it into a dispatch switch.
And with this, there are zero cycles in the references between the different "packageable" sections
of the UI. The only thing left to do is figure out how to redistribute `./elements` and `./components`
in a way that makes sense for each.
* Changed function name from 'emailMessageBody' to 'githubIssueMessageBody' to better reflect its usage.
* web: added comments about length and purpose of githubIssueMessageBody.
* Update web/src/common/labels.ts
Co-authored-by: Jens L. <jens@goauthentik.io>
Signed-off-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>
* Unwanted change.
---------
Signed-off-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>
Co-authored-by: Jens L. <jens@goauthentik.io>
* Web: Detangling some circular dependencies in Admin and User
Admin, User, and Flow should not dependend upon each other, at least
not in a circular way. If Admin and User depend on Flow, that's
fine, but Flow should not correspondingly depend upon elements of
either; if they have something in common, let's put them in
`@goauthentik/common` or find some other smart place to store them.
This commit refactors the intentToLabel and actionToLabel functions
into `@goauthentik/common/labels` and converts them to static tables
for maintenance purposes.
* web: "Consistency is the hobgoblin of small minds" - Ralph Waldo Emerson
* web: I found these confusing to look at, so I added comments.
* web: remove admin-to-user component reference(s)
There was only one: AppIcon. This has been moved to `components`.
Touching the LibraryApplications page triggered a cyclomatic
complexity check. Extracting the expansion block and streamlining
the class and style declarations with lit directives helped.
* web: remove admin from elements
This commit removes the two references from `elements` to `admin`: the list of UserEvents and a
reference to the FlowSearch type, used by the Forms manager to decide how to extract a value.
For FlowSearch, a different convention for detecting the type was implemented (instances of the
object have a unique fieldname for the value holder). UserEvents and ObjectChangelog have been
moved to `components` as they're clearly dependent upon the API.
This defers work on removing Admin from Components, as that is (again) references going the
wrong way, but that can happen later.
* web: remove admin-to-user component reference(s) (#6856)
There was only one: AppIcon. This has been moved to `components`.
Touching the LibraryApplications page triggered a cyclomatic
complexity check. Extracting the expansion block and streamlining
the class and style declarations with lit directives helped.
* This was supposed to be merged.
* Web: Detangling some circular dependencies in Admin and User
Admin, User, and Flow should not dependend upon each other, at least
not in a circular way. If Admin and User depend on Flow, that's
fine, but Flow should not correspondingly depend upon elements of
either; if they have something in common, let's put them in
`@goauthentik/common` or find some other smart place to store them.
This commit refactors the intentToLabel and actionToLabel functions
into `@goauthentik/common/labels` and converts them to static tables
for maintenance purposes.
* web: "Consistency is the hobgoblin of small minds" - Ralph Waldo Emerson
* web: I found these confusing to look at, so I added comments.
* web: remove admin-to-user component reference(s) (#6856)
There was only one: AppIcon. This has been moved to `components`.
Touching the LibraryApplications page triggered a cyclomatic
complexity check. Extracting the expansion block and streamlining
the class and style declarations with lit directives helped.
* web: Replace ad-hoc toggle control with ak-toggle-group
This commit replaces various ad-hoc implementations of the Patternfly Toggle Group HTML with a web
component that encapsulates all of the needed behavior and exposes a single API with a single event
handler, return the value of the option clicked.
The results are: Lots of visual clutter is eliminated. A single link of:
```
<div class="pf-c-toggle-group__item">
<button
class="pf-c-toggle-group__button ${this.mode === ProxyMode.Proxy
? "pf-m-selected"
: ""}"
type="button"
@click=${() => {
this.mode = ProxyMode.Proxy;
}}>
<span class="pf-c-toggle-group__text">${msg("Proxy")}</span>
</button>
</div>
<div class="pf-c-divider pf-m-vertical" role="separator"></div>
```
Now looks like:
```
<option value=${ProxyMode.Proxy}>${msg("Proxy")}</option>
```
This also means that the three pages that used the Patternfly Toggle Group could eliminate all of
their Patternfly PFToggleGroup needs, as well as the `justify-content: center` extension, which also
eliminated the `css` import.
The savings aren't as spectacular as I'd hoped: removed 178 lines, but added 123; total savings 55
lines of code. I still count this a win: we need never write another toggle component again, and
any bugs, extensions or features we may want to add can be centralized or forked without risking the
whole edifice.
* web: minor code formatting issue.
* web: adding a storybook for the ak-toggle-group component
* Bugs found by CI/CD.
* web: Replace ad-hoc search for CryptoCertificateKeyPairs with crypto-certificate-search (#6475)
* web: Replace ad-hoc search for CryptoCertificateKeyPairs with ak-crypto-certeficate-search
This commit replaces various ad-hoc implementations of `search-select` for CryptoCertificateKeyPairs
with a web component that encapsulates all of the needed behavior and exposes a single API.
The results are: Lots of visual clutter is eliminated. A single search of:
```HTML
<ak-search-select
.fetchObjects=${async (query?: string): Promise<CertificateKeyPair[]> => {
const args: CryptoCertificatekeypairsListRequest = {
ordering: "name",
hasKey: true,
includeDetails: false,
};
if (query !== undefined) {
args.search = query;
}
const certificates = await new CryptoApi(
DEFAULT_CONFIG,
).cryptoCertificatekeypairsList(args);
return certificates.results;
}}
.renderElement=${(item: CertificateKeyPair): string => {
return item.name;
}}
.value=${(item: CertificateKeyPair | undefined): string | undefined => {
return item?.pk;
}}
.selected=${(item: CertificateKeyPair): boolean => {
return this.instance?.tlsVerification === item.pk;
}}
?blankable=${true}
>
</ak-search-select>
```
Now looks like:
```HTML
<ak-crypto-certificate-search certificate=${this.instance?.tlsVerification}>
</ak-crypto-certificate-search>
```
There are three searches that do not require there to be a valid key with the certificate; these are
supported with the boolean property `nokey`; likewise, there is one search (in SAMLProviderForm)
that states that if there is no current certificate in the SAMLProvider and only one certificate can
be found in the Authentik database, use that one; this is supported with the boolean property
`singleton`.
These changes replace 382 lines of object-oriented invocations with 36 lines of declarative
configuration, and 98 lines for the class. Overall, the code for "find a crypto certificate" has
been reduced by 46%.
Suggestions for a better word than `singleton` are welcome!
* web: display tests for CryptoCertificateKeypair search
This adds a Storybook for the CryptoCertificateKeypair search, including
a mock fetch of the data. In the course of running the tests, we discovered
that including the SearchSelect _class_ won't include the customElement declaration
unless you include the whole file! Other bugs found: including the CSS from
Storybook is different from that of LitElement native, so much so that the
adapter needed to be included. FlowSearch had a similar bug. The problem
only manifests when building via Webpack (which Storybook uses) and not
Rollup, but we should support both in distribution.
Ken Sternberg
Jens L