The `FeatureToggleListTable` is nested directly within `PageContent`.
`PageContent` was cause for removing the skeleton from the table.
However, this is unnecessary because the table has its own loader that
manages the skeletons. Therefore, `PageContent` does not require a
loader.
This PR adds a 'change-request-conflict-created' event whenever someone
save a strategy update for a strategy that's used in either pending or
scheduled change requests.
Data for pending change requests will only be sent if change requests
are enabled. Data for scheduled change requests will be sent regardless.
Getting this data is somewhat involved, so I've extracted as much of the
logic into a separate file as possible.
The event re-uses the existing `change_request` metric and sends the
following data for each change request that we discover conflicts on:
```ts
{
state: ChangeRequestState,
changeRequest: string, // <unleash identifier>#<change request id>
action: 'edit-strategy',
eventType: 'conflict-created'
}
```
There's only one action for this for now, but we could expand this event
to things such as strategy deletion, feature archival, in the future.
That said, I'd be happy to take it out.
## Discussion points
### Has the strategy actually been updated?
This does not check whether a strategy has actually changed before
emitting the event, only that you save your strategy changes.
This assumes that most people will simply close the modal by
clicking/tapping outside it or using the escape key instead of pressing
save.
However, it will likely lead to some false positives. If we think that
is an issue, I would suggest adding a check that something in the
strategy has actually changed in a follow-up PR.
Added conflict count to CR metrics and CR id.
Something to think about:
There was idea that we can aggregate this data based on CR id, but CR id
is just a number from 0 to x. So it will not be unique across instances.
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
Includes some small fixes and improvements to the actions table UI:
- Fix webhook icon not properly loading
- Make actions execution param names bold in the tooltip
- Make filters param names bold in the tooltip
Only triggers if there is any rows in client instances that have
sdk_version: unleash-edge with version < 17.0.0
The function that checks this memoizes the check for 10 minutes to avoid
scanning the client instances table too often.
This PR fixes a bug in the displayed value of the conflict list so that
it shows the value it would update to instead of the snapshot value.
In doing so, it updates the logic of the algorithm to:
1. if the snapshot value and the current value are the same, it's not a
conflict (it's an intended change)
2. If the snapshot value differs from the current value, it is a
conflict if and only if the value in the change differs from the current
value. Otherwise, it's not a conflict.
The new test cases are:
- it shows a diff for a property if the snapshot and live version differ
for that property and the changed value is different from the live
version
- it does not show a diff for a property if the live version and the
change have the same value, even if the snapshot differs from the live
version
- it does not show a diff for a property if the snapshot and the live
version are the same
I noticed some manual `hasAccess` usages in permission guards due to the
fact that `PermissionGuard` does not accept `project` and `environment`.
This PR adds this support to `PermissionGuard` so we can adapt these
`hasAccess` checks to use it instead, adding consistency and cleaning
things up.
This PR does not include these adaptations however, it only adds the
optional properties to the component. We can address these at a later
point.
Connected to [#5932](https://github.com/Unleash/unleash/pull/5932) -
This starts using the new permissions in addition to the old
UPDATE_PROJECT permission. That way, if you're happy with
UPDATE_PROJECT, you don't need to change.
However, you can now add more fine grained permissions for both READ and
WRITE operations.
This PR will allow us to use a feature flag with variants to control
whether or not we should show the comments field of the feedback form.
This will allow us to see whether we can increase feedback collection if
we reduce the load on the customer.
This changes the badge element to prefer spans instead of divs. The
primary difference between spans and divs is that spans are inline and
divs are block. Styling-wise, we override the display property anyway.
Semantically, most all of the badges are used inline instead of on
their own block level, so this change seems sensible. You can still
provide `div` as the `as` prop if you need to.
This PR adds the `key` property to the features cell component where it
renders lists of flags. This fixes a few rendering errors we've been
getting in the console.
A strategy title can be either an empty string or undefined on the
type we use in the frontend. In the snapshot it can be an empty
string, null (presumably), and undefined.
This change updates the diffing logic to handle the various title diff
cases correctly. It also updates the type used for the snapshot to
reflect this.
This change adds an algorithm with tests for detecting what changes
would be overwritten by applying a CR.
Test cases:
- It compares strategies regardless of order of keys in the objects.
This ensures that two strategies with the same content but different
order of keys are compared correctly.
- It treats `undefined` or missing segments in old config as equal to
`[]` in change
- It treats `undefined` or missing strategy variants in old config and
change as equal to `[]`
- It lists changes in a sorted list with the correct values
- It ignores object order on nested objects. Similar to the first
point, this does order-insensitive comparison for nested objects (such
as params and constraints).
Uses a new `URL_SAFE_BASIC` regex constant that checks for characters
that are commonly used in URL path sections: alphanumeric lowercase
characters, dashes and underscores.
This will allow us to re-use this constant in our server-side
validation.
Since we've now added PAT's we really do recommend switching to those,
or for enterprises, we recommend using service accounts.
Admin tokens have an obvious disadvantage in that they're not connected
to any user, so actions performed by them are harder to audit.
This PR adds a killswitch for turning it off, in preparation for
deprecating them and ultimately removing them in the future.
This improves the role resolution in the value of the default root role,
preventing a bug where settings saved
pre-https://github.com/Unleash/unleash/pull/5887 would show an empty
default root role in the dropdown.
Also makes the role update more robust.
This PR adds uuids as ids using a symbol in order to make sure we only
use this to keep internal order in the viritual DOM. This makes us able
to have predictable mutable lists on the frontend, and makes it easy to
not pass this property along to the backend.
This seems to improve the performance in the role form while still
maintaining the same validation logic.
A big factor was the memoization of the categories calculation and
respective elements, which is especially impactful when there are many
environments.
This PR adds undo functionality so you can restore the state of your
constraint if you make a mistake. We also amend the autosave
functionality to only apply when values are changed and you have a valid
value. See demo:
https://www.loom.com/share/da704da8aee94ac18d4caae697426802
[](https://renovatebot.com)
This PR contains the following updates:
| Package | Change | Age | Adoption | Passing | Confidence |
|---|---|---|---|---|---|
| [react-router](https://togithub.com/remix-run/react-router)
([source](https://togithub.com/remix-run/react-router/tree/HEAD/packages/react-router))
| [`6.20.1` ->
`6.21.1`](https://renovatebot.com/diffs/npm/react-router/6.20.1/6.21.1)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
| [react-router-dom](https://togithub.com/remix-run/react-router)
([source](https://togithub.com/remix-run/react-router/tree/HEAD/packages/react-router-dom))
| [`6.20.1` ->
`6.21.1`](https://renovatebot.com/diffs/npm/react-router-dom/6.20.1/6.21.1)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
[](https://docs.renovatebot.com/merge-confidence/)
|
---
### Release Notes
<details>
<summary>remix-run/react-router (react-router)</summary>
###
[`v6.21.1`](https://togithub.com/remix-run/react-router/blob/HEAD/packages/react-router/CHANGELOG.md#6211)
[Compare
Source](https://togithub.com/remix-run/react-router/compare/react-router@6.21.0...react-router@6.21.1)
##### Patch Changes
- Fix bug with `route.lazy` not working correctly on initial SPA load
when `v7_partialHydration` is specified
([#​11121](https://togithub.com/remix-run/react-router/pull/11121))
- Updated dependencies:
- `@remix-run/router@1.14.1`
###
[`v6.21.0`](https://togithub.com/remix-run/react-router/blob/HEAD/packages/react-router/CHANGELOG.md#6210)
[Compare
Source](https://togithub.com/remix-run/react-router/compare/react-router@6.20.1...react-router@6.21.0)
##### Minor Changes
- Add a new `future.v7_relativeSplatPath` flag to implement a breaking
bug fix to relative routing when inside a splat route.
([#​11087](https://togithub.com/remix-run/react-router/pull/11087))
This fix was originally added in
[#​10983](https://togithub.com/remix-run/react-router/issues/10983)
and was later reverted in
[#​11078](https://togithub.com/remix-run/react-router/pull/11078)
because it was determined that a large number of existing applications
were relying on the buggy behavior (see
[#​11052](https://togithub.com/remix-run/react-router/issues/11052))
**The Bug**
The buggy behavior is that without this flag, the default behavior when
resolving relative paths is to *ignore* any splat (`*`) portion of the
current route path.
**The Background**
This decision was originally made thinking that it would make the
concept of nested different sections of your apps in `<Routes>` easier
if relative routing would *replace* the current splat:
```jsx
<BrowserRouter>
<Routes>
<Route path="/" element={<Home />} />
<Route path="dashboard/*" element={<Dashboard />} />
</Routes>
</BrowserRouter>
```
Any paths like `/dashboard`, `/dashboard/team`, `/dashboard/projects`
will match the `Dashboard` route. The dashboard component itself can
then render nested `<Routes>`:
```jsx
function Dashboard() {
return (
<div>
<h2>Dashboard</h2>
<nav>
<Link to="/">Dashboard Home</Link>
<Link to="team">Team</Link>
<Link to="projects">Projects</Link>
</nav>
<Routes>
<Route path="/" element={<DashboardHome />} />
<Route path="team" element={<DashboardTeam />} />
<Route path="projects" element={<DashboardProjects />} />
</Routes>
</div>
);
}
```
Now, all links and route paths are relative to the router above them.
This makes code splitting and compartmentalizing your app really easy.
You could render the `Dashboard` as its own independent app, or embed it
into your large app without making any changes to it.
**The Problem**
The problem is that this concept of ignoring part of a path breaks a lot
of other assumptions in React Router - namely that `"."` always means
the current location pathname for that route. When we ignore the splat
portion, we start getting invalid paths when using `"."`:
```jsx
// If we are on URL /dashboard/team, and we want to link to
/dashboard/team:
function DashboardTeam() {
// ❌ This is broken and results in <a href="/dashboard">
return <Link to=".">A broken link to the Current URL</Link>;
// ✅ This is fixed but super unintuitive since we're already at
/dashboard/team!
return <Link to="./team">A broken link to the Current URL</Link>;
}
```
We've also introduced an issue that we can no longer move our
`DashboardTeam` component around our route hierarchy easily - since it
behaves differently if we're underneath a non-splat route, such as
`/dashboard/:widget`. Now, our `"."` links will, properly point to
ourself *inclusive of the dynamic param value* so behavior will break
from it's corresponding usage in a `/dashboard/*` route.
Even worse, consider a nested splat route configuration:
```jsx
<BrowserRouter>
<Routes>
<Route path="dashboard">
<Route path="*" element={<Dashboard />} />
</Route>
</Routes>
</BrowserRouter>
```
Now, a `<Link to=".">` and a `<Link to="..">` inside the `Dashboard`
component go to the same place! That is definitely not correct!
Another common issue arose in Data Routers (and Remix) where any
`<Form>` should post to it's own route `action` if you the user doesn't
specify a form action:
```jsx
let router = createBrowserRouter({
path: "/dashboard",
children: [
{
path: "*",
action: dashboardAction,
Component() {
// ❌ This form is broken! It throws a 405 error when it submits because
// it tries to submit to /dashboard (without the splat value) and the
parent
// `/dashboard` route doesn't have an action
return <Form method="post">...</Form>;
},
},
],
});
```
This is just a compounded issue from the above because the default
location for a `Form` to submit to is itself (`"."`) - and if we ignore
the splat portion, that now resolves to the parent route.
**The Solution**
If you are leveraging this behavior, it's recommended to enable the
future flag, move your splat to it's own route, and leverage `../` for
any links to "sibling" pages:
```jsx
<BrowserRouter>
<Routes>
<Route path="dashboard">
<Route index path="*" element={<Dashboard />} />
</Route>
</Routes>
</BrowserRouter>
function Dashboard() {
return (
<div>
<h2>Dashboard</h2>
<nav>
<Link to="..">Dashboard Home</Link>
<Link to="../team">Team</Link>
<Link to="../projects">Projects</Link>
</nav>
<Routes>
<Route path="/" element={<DashboardHome />} />
<Route path="team" element={<DashboardTeam />} />
<Route path="projects" element={<DashboardProjects />} />
</Router>
</div>
);
}
```
This way, `.` means "the full current pathname for my route" in all
cases (including static, dynamic, and splat routes) and `..` always
means "my parents pathname".
##### Patch Changes
- Properly handle falsy error values in ErrorBoundary's
([#​11071](https://togithub.com/remix-run/react-router/pull/11071))
- Updated dependencies:
- `@remix-run/router@1.14.0`
</details>
<details>
<summary>remix-run/react-router (react-router-dom)</summary>
###
[`v6.21.1`](https://togithub.com/remix-run/react-router/blob/HEAD/packages/react-router-dom/CHANGELOG.md#6211)
[Compare
Source](https://togithub.com/remix-run/react-router/compare/react-router-dom@6.21.0...react-router-dom@6.21.1)
##### Patch Changes
- Updated dependencies:
- `react-router@6.21.1`
- `@remix-run/router@1.14.1`
###
[`v6.21.0`](https://togithub.com/remix-run/react-router/blob/HEAD/packages/react-router-dom/CHANGELOG.md#6210)
[Compare
Source](https://togithub.com/remix-run/react-router/compare/react-router-dom@6.20.1...react-router-dom@6.21.0)
##### Minor Changes
- Add a new `future.v7_relativeSplatPath` flag to implement a breaking
bug fix to relative routing when inside a splat route.
([#​11087](https://togithub.com/remix-run/react-router/pull/11087))
This fix was originally added in
[#​10983](https://togithub.com/remix-run/react-router/issues/10983)
and was later reverted in
[#​11078](https://togithub.com/remix-run/react-router/pull/11078)
because it was determined that a large number of existing applications
were relying on the buggy behavior (see
[#​11052](https://togithub.com/remix-run/react-router/issues/11052))
**The Bug**
The buggy behavior is that without this flag, the default behavior when
resolving relative paths is to *ignore* any splat (`*`) portion of the
current route path.
**The Background**
This decision was originally made thinking that it would make the
concept of nested different sections of your apps in `<Routes>` easier
if relative routing would *replace* the current splat:
```jsx
<BrowserRouter>
<Routes>
<Route path="/" element={<Home />} />
<Route path="dashboard/*" element={<Dashboard />} />
</Routes>
</BrowserRouter>
```
Any paths like `/dashboard`, `/dashboard/team`, `/dashboard/projects`
will match the `Dashboard` route. The dashboard component itself can
then render nested `<Routes>`:
```jsx
function Dashboard() {
return (
<div>
<h2>Dashboard</h2>
<nav>
<Link to="/">Dashboard Home</Link>
<Link to="team">Team</Link>
<Link to="projects">Projects</Link>
</nav>
<Routes>
<Route path="/" element={<DashboardHome />} />
<Route path="team" element={<DashboardTeam />} />
<Route path="projects" element={<DashboardProjects />} />
</Routes>
</div>
);
}
```
Now, all links and route paths are relative to the router above them.
This makes code splitting and compartmentalizing your app really easy.
You could render the `Dashboard` as its own independent app, or embed it
into your large app without making any changes to it.
**The Problem**
The problem is that this concept of ignoring part of a path breaks a lot
of other assumptions in React Router - namely that `"."` always means
the current location pathname for that route. When we ignore the splat
portion, we start getting invalid paths when using `"."`:
```jsx
// If we are on URL /dashboard/team, and we want to link to
/dashboard/team:
function DashboardTeam() {
// ❌ This is broken and results in <a href="/dashboard">
return <Link to=".">A broken link to the Current URL</Link>;
// ✅ This is fixed but super unintuitive since we're already at
/dashboard/team!
return <Link to="./team">A broken link to the Current URL</Link>;
}
```
We've also introduced an issue that we can no longer move our
`DashboardTeam` component around our route hierarchy easily - since it
behaves differently if we're underneath a non-splat route, such as
`/dashboard/:widget`. Now, our `"."` links will, properly point to
ourself *inclusive of the dynamic param value* so behavior will break
from it's corresponding usage in a `/dashboard/*` route.
Even worse, consider a nested splat route configuration:
```jsx
<BrowserRouter>
<Routes>
<Route path="dashboard">
<Route path="*" element={<Dashboard />} />
</Route>
</Routes>
</BrowserRouter>
```
Now, a `<Link to=".">` and a `<Link to="..">` inside the `Dashboard`
component go to the same place! That is definitely not correct!
Another common issue arose in Data Routers (and Remix) where any
`<Form>` should post to it's own route `action` if you the user doesn't
specify a form action:
```jsx
let router = createBrowserRouter({
path: "/dashboard",
children: [
{
path: "*",
action: dashboardAction,
Component() {
// ❌ This form is broken! It throws a 405 error when it submits because
// it tries to submit to /dashboard (without the splat value) and the
parent
// `/dashboard` route doesn't have an action
return <Form method="post">...</Form>;
},
},
],
});
```
This is just a compounded issue from the above because the default
location for a `Form` to submit to is itself (`"."`) - and if we ignore
the splat portion, that now resolves to the parent route.
**The Solution**
If you are leveraging this behavior, it's recommended to enable the
future flag, move your splat to it's own route, and leverage `../` for
any links to "sibling" pages:
```jsx
<BrowserRouter>
<Routes>
<Route path="dashboard">
<Route index path="*" element={<Dashboard />} />
</Route>
</Routes>
</BrowserRouter>
function Dashboard() {
return (
<div>
<h2>Dashboard</h2>
<nav>
<Link to="..">Dashboard Home</Link>
<Link to="../team">Team</Link>
<Link to="../projects">Projects</Link>
</nav>
<Routes>
<Route path="/" element={<DashboardHome />} />
<Route path="team" element={<DashboardTeam />} />
<Route path="projects" element={<DashboardProjects />} />
</Router>
</div>
);
}
```
This way, `.` means "the full current pathname for my route" in all
cases (including static, dynamic, and splat routes) and `..` always
means "my parents pathname".
##### Patch Changes
- Updated dependencies:
- `@remix-run/router@1.14.0`
- `react-router@6.21.0`
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "after 7pm every weekday,before 5am
every weekday" in timezone Europe/Madrid, Automerge - At any time (no
schedule defined).
🚦 **Automerge**: Enabled.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about these
updates again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Mend
Renovate](https://www.mend.io/free-developer-tools/renovate/). View
repository job log
[here](https://developer.mend.io/github/Unleash/unleash).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4xMjcuMCIsInVwZGF0ZWRJblZlciI6IjM3LjEyNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
