web/user: fix search not updating app (#7825)
web/user: fix app not updating
so when using two classes in a classMap directive, the update fails (basically saying that each class must be separated), however this error only shows when directly calling requestUpdate and is swallowed somewhere when relying on the default render cycle
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Jens L <jens@goauthentik.io>
web: fix overflow glitch on ak-page-header (#7883)
By adding 'grow' but not 'shrink' to the header section, the page was allowed to allocate
as much width as was available when the window opened, but not allowed to resize the width
if it was pushed closed by zoom, page resize, or summon sidebar.
This commit adds 'shrink' to the capabilities of the header.
Co-authored-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>
Web: bugfix: broken backchannel selector (#7480)
* 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.
* web: bugfix: broken backchannel selector
There were two bugs here, both of them introduced by me because I didn't understand the
system well enough the first time through, and because I didn't test thoroughly enough.
The first is that I was calling the wrong confirmation code; the resulting syntax survived
because `confirm()` is actually a legitimate function call in the context of the DOM Window,
a legacy survivor similar to `alert()` but with a yes/no return value. Bleah.
The second is that the confirm code doesn't appear to pass back a dictionary with the
`{ items: Array<Provider> }` list, it passes back just the `items` as an Array.
Co-authored-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>
web/admin: fix html error on oauth2 provider page (#7384)
* 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.
* \# Details
Extra `>` symbol screwed up the reading of the rest of the component. Unfortunately,
too many fields in an input are optional, so it was easy for this bug to bypass any
checks by the validators. I should have caught it myself, though.
Co-authored-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>
* 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
I'm conducting a more comprehensive survey of the UI in order to get a more holistic idea of the
changes that should be implemented. Along the way, I'm finding a few small details that annoy me.
Here are three.
It goes to "User statistics." I have changed both the text of the link and the page to read "User
Statistics" (it's a title, it should be capitalized).
Give people warning when you're about to take them out of the system, especially if you're opening a
new tab along the way.
Just a thing I spotted along the way.
* 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: isolate clipboard handling
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.
* web: break out the recovery link logic into a standalone function
UserViewPage and UserLinkPage have the same functionality to request to view a
link with which a user may access an account recovery flow. The language and
error messages were different on both of those pages. This commit harmonizes
the language by making the request a standalone function. It also exploits the
breakout of the "write to clipboard" commit to write the link to the clipboard,
and to inform the user that the clipboard has been written to, when possible.
* web: parity between UserViewPage and UserListPage
Since the UserListPage's "accordion" view has an offer to "Email
the recovery link" to the user, it seemed appropriate to grant the
same capability to the UserListPage.
* web: harmonize the CSS.
After a bit of messing around, I have also ensured that the gap between the buttons is
the same in all cases, that in the columnar display the buttons are of uniform width,
and that the buttons have the same next:
- "Set Password"
- "View Recovery Link"
- "Email Recovery Link"
NOTE: This commit is contingent upon the PR for [isolate clipboard
handling](https://github.com/goauthentik/authentik/pull/7229) to
be accepted, as it relies on the clipboard handler for the "write
link to clipboard" feature.
* web: ensure the existence of the user
Every `...render()` method in the UserViewPage class has a preamble
guard clause:
```
if (!this.user) {
return html``;
}
```
With this clause, it should not be necessary to repeatedly check
the type of `this.user` throughout the rest of the method, but the
nominal type is `User?`, which means that functions called from
within the method need to be protected against `undefined` failure.
By creating a new variable with the type after the guard clause,
we ensure the type is `User` (no question!) and can safely use it
without those checks.
Along the way, I replaced the empty html with `nothing` and corrected
(mostly by removing) the return types.
References:
- [Lit-HTML: Prefer `nothing` over empty html or other falsey walues](https://lit.dev/docs/api/templates/#nothing)
- [TypeScript: Type annotations on return types are rarely
necessary](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#:~:text=Return%20Type%20Annotations&text=Much%20like%20variable%20type%20annotations,example%20doesn't%20change%20anything.)
* web: accepting suggested label change
gcp-cherry-pick-bot[bot]
Jens L
transifex-integration[bot]
authentik-automation[bot]
dependabot[bot]
Ken Sternberg
Marc 'risson' Schmitt