cc781cad00
* 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 |
||
|---|---|---|
| .. | ||
| admin-overview | ||
| applications | ||
| blueprints | ||
| common | ||
| crypto | ||
| enterprise | ||
| events | ||
| flows | ||
| groups | ||
| outposts | ||
| policies | ||
| property-mappings | ||
| providers | ||
| roles | ||
| sources | ||
| stages | ||
| system-tasks | ||
| tenants | ||
| tokens | ||
| users | ||
| AdminInterface.ts | ||
| DebugPage.ts | ||
| helperText.ts | ||
| Routes.ts | ||