* dev:
web: bump @sentry/browser from 7.114.0 to 8.2.1 in /web in the sentry group across 1 directory (#9757)
core, web: update translations (#9714)
core: bump sentry-sdk from 2.1.1 to 2.2.0 (#9753)
core: bump selenium from 4.20.0 to 4.21.0 (#9754)
core: bump msgraph-sdk from 1.2.0 to 1.4.0 (#9755)
core: bump github.com/sethvargo/go-envconfig from 1.0.1 to 1.0.2 (#9756)
web: bump chromedriver from 124.0.3 to 125.0.0 in /tests/wdio (#9758)
website/docs: new PR for the Entra provider docs (ignore old one) (#9741)
This commit documents and adds unit tests for our `Labels` component, which are usually called
"chips" in other design systems.
I've also reverted to allowing the components that take 'level' information to take it as a single
argument that is _either_ an attribute or a property. If it's a property, it reverts to the older
behavior.
This commit adds unit tests for the Alerts and EmptyState elements. It includes a new
test/documentation feature; elements can now be fully documented with text description and active
controls.
It *removes* the `babel` imports entirely. Either we don't need them, or the components that do
need them are importing them automatically.
[An outstanding bug in WebDriverIO](https://github.com/webdriverio/webdriverio/issues/12056)
unfortunately means that the tests cannot be run in parallel for the time being.While one test is
running, the compiler for other tests becomes unreliable. They're currently working on this issue.
I have set the `maxInstances` to **1**.
I have updated the `<ak-alert>` component just a bit, providing an attribute alternative to the
`Level` property; now instead of passing it a `<ak-alert level=${Levels.Warning}>` properties, you
can just say `<ak-alert warning>` and it'll work just fine. The old way is still the default
behavior.
The default behavior for `EmptyState` was a little confusing; I've re-arranged it for clarity. Since
I touched it, I also added the `interface` and `HTMLElementTagNameMap` declarations.
Added documentation to all the elements I've touched (so far).
* main:
root: include task_id in events and logs (#9749)
web: bump the esbuild group in /web with 2 updates (#9745)
web: bump esbuild from 0.21.2 to 0.21.3 in /web (#9746)
web: bump the storybook group across 1 directory with 7 updates (#9747)
This commit provides tests alongside the stories for the aggregate cards. The tests are fairly
basic, but they're good enough for starting *and* they provide a pretty good example of how to test
when a promise with a delay is involved.
Two minor fixes in this code:
- The subtext was given a small amount of whitespace above, to remove the crowding that happened.
It looks much better with a half-rem of space.
- In the rare case that we have a card header with no icon, the ' ' symbol that separates the
icon from the header is now not rendered. In the previous form, it would push the header to the
left, making it "hang in space" one rem to the right of the visual line formed by the rightmost
content border. The padding between the header, body, and footer is odd; body is 1 rem, the
header and footer 2rems. This looks good for the graphs, but for the text, not so much.
After examining how people like Adobe and Salesforce do things, I have updated the storybook
configuration to provide run-time configuration of light/dark mode (although right now nothing
happens), inject the correct styling into the page, and update the preview handling so that we can
see the components better. We'll see how this pans out.
I have provided stories for the AggregateCard, AggregatePromiseCard, and a new QuickActionsCard. I
also fixed a bug in AggregatePromiseCard where it would fail to report a fetch error. It will only
report that "the operation falied," but it will give the full error into the console.
**As an experiment**, I have changed the interpreter for `lint:precommit` and `build:watch` to use
[Bun](https://bun.sh/) instead of NodeJS. We have observed significant speed-ups and much better
memory management with Bun for these two operations. Those are both developer-facing operations, the
behavior of the system undur current CI/CD should not change.
And finally, I've switched the QuickActionsCard view in Admin-Overview to use the new component.
Looks the same. Reads *way* easier. :-)
* dev:
web: bump esbuild from 0.21.1 to 0.21.2 in /web (#9696)
web: bump chromedriver from 124.0.2 to 124.0.3 in /tests/wdio (#9692)
website: bump @types/react from 18.3.1 to 18.3.2 in /website (#9691)
core, web: update translations (#9672)
core: bump psycopg from 3.1.18 to 3.1.19 (#9698)
core: bump google-api-python-client from 2.128.0 to 2.129.0 (#9694)
web: bump the esbuild group in /web with 2 updates (#9695)
web: bump glob from 10.3.14 to 10.3.15 in /web (#9697)
core: bump freezegun from 1.5.0 to 1.5.1 (#9693)
web: fix value handling inside controlled components (#9648)
* 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: fix value handling inside controlled components
This is one of those stupid bugs that drive web developers crazy. The basics are straightforward:
when you cause a higher-level component to have a "big enough re-render," for some unknown
definition of "big enough," it will re-render the sub-components. In traditional web interaction,
those components should never be re-rendered while the user is interacting with the form, but in
frameworks where there's dynamic re-arrangement, part or all of the form could get re-rendered at
any mmoment. Since neither the form nor any of its intermediaries is tracking the values as they're
changed, it's up to the components themselves to keep the user's input-- and to be hardened against
property changes coming from the outside world.
So static memoization of the initial value passed in, and aggressively walling off the values the
customer generates from that field, are needed to protect the user's work from any framework's
dynamic DOM management. I remember struggling with this in React; I had hoped Lit was better, but in
this case, not better enough.
The protocol for "is it an ak-data-control" is "it has a `json()` method that returns the data ready
to be sent to the authentik server." I missed that in one place, so that's on me.
* Eslint had opinions.
* Added comments to explain something.
As is typical of a system where a new build engine is involved, this thing is sadly fragile. Use the
wrong import style in wdio.conf.js and it breaks; there are several notes in tsconfig.test.conf and
wdio.conf.ts to tell eslint or tsc not to complain, it's just a different build with different
criteria, the native criteria don't apply.
On the other hand, writing tests is easy and predictable. We can test behaviors at the unit and
component scale in a straightforward manner, and validate our expectations that things work the way
we believe they should.
* 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: clean up a bit inside the promptform
Just something I did while researching Github Issue 5197.
