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.
