- style for headers in Insights dashboard and project selector
- fixed React element key issue in gauge chart
- fixed React attribute issue in Health stats
- active/inactive user stats from backend
This PR moves the CR specific logic out of the MultiActionButton and
generalises so that we can re-use it across the application. The CR
specific logic is moved into:
* ApplyButton.tsx
* ReviewButton.tsx
This fixes a bug where multi action button would be disabled if you
tried to apply an approved change request that you had created yourself.
This PR adds warning icons to the environment selector for environments
that have problems detected. However, because we don't have any way
detect problems yet, this PR only adds the icons and the infrastructure
to display them. They're always set to "not displayed" for now.
The icons have "problems detected" as accessible text.
It looks like this when you add them in (for every environment):
<img width="1137" alt="image"
src="https://github.com/Unleash/unleash/assets/17786332/c29bfa52-ddee-4b16-b3ac-5c1f8fcc326e">
In order to prevent users from being able to assign roles/permissions
they don't have, this PR adds a check that the user performing the
action either is Admin, Project owner or has the same role they are
trying to grant/add.
This addAccess method is only used from Enterprise, so there will be a
separate PR there, updating how we return the roles list for a user, so
that our frontend can only present the roles a user is actually allowed
to grant.
This adds the validation to the backend to ensure that even if the
frontend thinks we're allowed to add any role to any user here, the
backend can be smart enough to stop it.
We should still update frontend as well, so that it doesn't look like we
can add roles we won't be allowed to.
This PR adds an environment selector to the connected instances table,
using query parameters to store the environment selection.
I'm still using the old data to populate this, so it'll show you all
data when nothing is selected and only filtered data when you select an
env. There is no way to unselect an env at the moment: I'm not sure
that's something we'll need to do, so we'll handle that when we know.
I imagine in the future, we might update the component to make separate
calls per environments and a call to determine which envs are available,
but for now, this will do just fine.
<img width="848" alt="image"
src="https://github.com/Unleash/unleash/assets/17786332/ef7562d5-c0ab-48c6-ba43-7c0007719ab4">
This PR adds a new file "Application.tsx", which is analogous to the
existing Project.tsx file in that it contains the base layout for the
application page, as well as tabs pointing to sub pages. Currently, the
overview tab uses a paragraph with some fallback text, while the
connected instances table displays the instances table.
I have mostly copied the existing ApplicationEdit component and used
that as a base, assuming that we'll delete that component when we're
done with this.
<img width="1449" alt="image"
src="https://github.com/Unleash/unleash/assets/17786332/ac574a83-3cf4-4de5-a4de-188575074ecb">
This PR adds a first iteration of the connected instances table on a new
connected instances tab of the application page (hidden behind a flag).
As a first version, it only uses data that we currently return for each
application (so no "connected through" or "last synchronized").
It also uses the existing version of the application data and just
filters it for the "production" environment right now.
Adding query parameters (and potentially a new URL?) to the applications
page (to save state and fetch data) will be done in a follow-up. This
should lay the groundwork for adding a new API too.
<img width="1485" alt="image"
src="https://github.com/Unleash/unleash/assets/17786332/4fb68456-d0f5-4f82-9246-5333a273df9c">
## About the changes
This is a rough initial version as a PoC for a permission matrix.
This is only available after enabling the flag `userAccessUIEnabled`
that is set to true by default in local development.
The access was added to the users' admin page but could be embedded in
different contexts (e.g. when assigning a role to a user):
This is how the matrix looks like
---------
Co-authored-by: Nuno Góis <github@nunogois.com>
The current approach uses adds an extra parameter to the components and
passes it through from the parent components. It's never a lot of
levels, so it feels alright, but it's feels like a bit of a code smell.
I wonder if it would make sense to use a context for each change
request? 🤔
Supersedes: https://github.com/Unleash/unleash/pull/6181
This PR updates the way we show deleted strategies in the CR UI. Instead
of showing just the strategy name and a diff on hover, we show the same
strategy config as we do for new and updated strategies.
This makes it easier to see what you have deleted.
In doing so, it also fixes two issues:
1. inconsistent border radius for segment changes listed. Due to an
override in `frontend/src/themes/theme.ts`, these would get a border
radius of `theme.shape.borderRadiusLarge` instead of
`theme.shape.borderRadiusMedium`. It does this by adding a class and
making the selector more specific.
2. The background was unset for the strategy rollout box and constraint
item boxes.
It looks like this:
<img width="728" alt="image"
src="https://github.com/Unleash/unleash/assets/17786332/7cba28ac-0454-444d-8cfa-f46543ccf2dc">
<img width="728" alt="image"
src="https://github.com/Unleash/unleash/assets/17786332/832be653-3def-4afc-b72f-36fcd76ad83d">
Or with more kinds of strategies:
<img width="454" alt="image"
src="https://github.com/Unleash/unleash/assets/17786332/f18e5482-7d2e-4cbd-8177-9de6dfb10307">
Note: I'm happy to isolate the color changes to a separate PR if that's
preferable.
Created a build script that generates orval schemas with automatic
cleanup. Also generating new ones.
1. yarn gen:api **(generates schemas)**
2. rm -rf src/openapi/apis **(remove apis)**
3. sed -i '1q' src/openapi/index.ts **(remove all rows except first)**
This PR adds showing of env variant conflicts in change requests.
This is a simple solution that only compares the total state of
variants. We *could* potentially do a modified version where we show
each and every variant as its own property. Because variants have to be
unique by name and because their names can't be changed after their
creation, we could create a map of variant name to their data.
<img width="1105" alt="image"
src="https://github.com/Unleash/unleash/assets/17786332/0c67f958-6c4e-453a-9791-0e132fb1f23e">
This PR adds an endpoint to Unleash that accepts an error message and
option error stack and logs it as an error. This allows us to leverage
errors in logs observability to catch UI errors consistently.
Considered a test, but this endpoint only accepts and logs input, so I'm
not sure how useful it would be.
React can sometimes be non-intuitive and behave erratically due to the
way it detects changes in hook dependencies.
This prevents infinite re-renders from `useIncomingWebhooks` by using a
static `DEFAULT_DATA` constant, so that its reference is always the
same, so no changes are detected when there are none.
Unrelated scouting, but this PR also removes an unneeded dependency in
the memoized columns in `ProjectActionsTable`.
Adds a new Inactive Users list component to admin/users for easier cleanup of users that are counted as inactive: No sign of activity (logins or api token usage) in the last 180 days.
---------
Co-authored-by: David Leek <david@getunleash.io>
Use React's context to track how many CRs are moved into their next
state with conflicts present.
This PR wraps environment change requests and change request overviews
in a change request plausible context that contains a
`willOverwriteStrategyChanges` property. This property is updated by the
diff calculation if there are any conflicts and then read by the
`changeState` function in the `useChangeRequestApi` hook.
As long as at least one of the strategies in the CR contain conflicts,
it will be marked as overwriting changes.
We had to make some updates to let the compiler know about the types and
fix an issue with nested objects not being compared as objects (instead
as strings), but this saves us a few lines and is hopefully more
readable.
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
Lots of work here, mostly because I didn't want to turn off the
`noImplicitAnyLet` lint. This PR tries its best to type all the untyped
lets biome complained about (Don't ask me how many hours that took or
how many lints that was >200...), which in the future will force test
authors to actually type their global variables setup in `beforeAll`.
---------
Co-authored-by: Gastón Fournier <gaston@getunleash.io>
This changes the two interfaces IChangeRequest and
IChangeRequestSchedule to be union types instead of interfaces. It also
extracts the constituents of those union types into proper types
themselves (so that they can be used in function type signatures etc).
It also updates the type names.
This turned out to be more work than I had imagined, but I think the end
result pays off, giving us more type safety and control.
I wanted to use just `ChangeRequest` for the IChangeRequest type, but
that caused issues due to naming collisions with the `ChangeRequest`
component that we have, causing tests to fail. I've named it
`ChangeRequestType` as a potential solution, but suggestions are
welcome.
The relevant changes are in
`frontend/src/component/changeRequest/changeRequest.types.ts`.
Everything else is updated references and some necessary refactoring to
respect the new types.
https://linear.app/unleash/issue/2-1817/ui-create-an-incoming-webhooks-configuration-page
This adds an incoming webhooks page with the respective table. We plan
on possibly extending the table with a couple more columns in a future
PR.
This allows us:
- View all configured incoming webhooks;
- Copy their URL to the clipboard;
- Remove them;
For "new" and "edit" operations we still need the incoming webhooks
form/dialog, coming in a future PR.
**Note**: Even though we are showing the full URL in the table for now,
we may end up truncating its start in the future (e.g.
`.../api/incoming-webhook/<webhook-name>` - This decision depends on how
it will look like after the rest of the columns are added.
This PR makes a change to how variants work in the new setup. Variants
will now:
* Be removed if you change tab or unmount the component and it has no
name
* Moved StrategyVariants into a separate component to isolate this
change
* Add error handling around onSubmit and only trigger feedback if it's
successful
