This PR adds the buttons (only UI, no functionality) to show either "all
projects" or "my projects".
The buttons use a styled button group and are hidden behind the new
`projectListFilterMyProjects` flag.
The button placement breaks with the previously established page header
pattern of having all actions moved to the right. To accommodate this
new placement, I created a new flex container in the header called
`leftActions`, which is essentially just a mirror of the normal actions.
I went with `leftActions` instead of `inlineStartActions` or something
similar because I think it's clearer, and I don't see us adapting
Unleash for different writing directions right now. We can always change
it later.
I have also slightly increased the end margin of the page header to
accommodate the new designs and to adjust the spacing before the
buttons. I adjusted the margin of the text instead of the padding of the
left actions because this will keep the spacing to the page header the
same on every page. Without it, we could end up in situations where the
spacing changes from page to page based on whether it has left actions
or not, which is probably undesirable.
## Still to do:
### Hover colors
~~Find out what the right hover color variable is. I'm using the light
mode hover color for now, which works well in both light and dark modes
(looks nice and is AAccessible), but it's not the same as the hover
color for other buttons in dark mode.~~
Fixed ☝🏼
### Small windows
Also worth noting: at around 500px, the layout shift starts to cause
problems and we end up with overlapping elements. How do we want to deal
with narrower screens? Today, the UI is pretty functional until we reach
about 250px. It would be nice to not increase that size.
The new version breaking at about 500px:
The old version breaking at about 250px:
### Margins
We also need to figure out how much space we want on smaller windows:
Converts `newContextFieldUI` release flag to
`disableShowContextFieldSelectionValues` kill switch.
The kill switch controls whether we show the value selection above the
search filed when > 100 values
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
Make the tooltip for project selection in the playground work properly
again. Right now, it doesn't work due to an error in react refs.
Because we wrap this in a tooltip in the Playground, we need to forward
the ref to the underlying component.
This follows the steps outlined in
https://mui.com/material-ui/guides/composition/#caveat-with-refs
Preview (eye icon) on a segment in "targetting" when creating or editing
a strategy now corectly shows details of a segment.
Previously it was not showing constraints present in this segment
Ivar pointed out to me that this was intended as an enterprise only
feature. So this PR makes it an enterprise only feature. Conditionally
render the link in the normal user table, and use premium feature
component if you happen to hit the route and not be running on the
enterprise plan.
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 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.
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 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 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 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>
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 removes the cancel button from the new constraint accordion.
Since we now do autosave when the constraint updates, cancel is no
longer needed, the done button and delete button is enough.
This PR adds autosave to the constraint accordion which means that when
you add values to it, it will automatically save the constraint locally.
If you unmount the constraint component without any valid values, it
will remove the constraint from the list.
Iterates on https://github.com/Unleash/unleash/pull/5762
While on the previous PR we would always open markdown links on a new
tab, we still want to navigate on the same tab when a relative link is
specified.
This adds a new `Markdown` common component with this logic by default,
which should make things a lot simpler and easier to maintain. The logic
that was followed is similar to the existing internal/external links
logic in our banners.
This PR refactores the StrategyVariants component to be passed in from
the outside to the new form component. This allows us to pass in the
StrategyVariants with an "editable" property in the create form which we
use to determine the editable state of the name input field. If the
editable field is not passed in we keep the old behavior.
Notable changes:
* StrategyVariants is now passed in from the outside, allowing us to
define different props at call time
* Added tests for the new behavior, and for keeping the old behavior
(such as in edit strategy)
* Added tracking
## Problem
The ConstraintAccordionList component was used in multiple places:
* Playground
* Segment form
* StrategyExecution
* Change requests
* Create strategy
* Edit strategy
This is problematic because some of the views are just pure visual
representations, and other views allow you to interact with and edit the
constraints. This causes a situation where the visual representation
needs to be aware of the implementation details of editing and mutating
constraints. In addition the ConstraintAccordionList is not just a pure
rendering of the list, it also keeps internal state on when to show the
create button and optional headers. This is makes it hard to make
changes when stylings need to be subtly different across components.
## Solution
Taking on the full refactor for this is out of scope, but it's
unfortunate that the ConstraintAccordionList needs all this internal
state. For now I split out the list into it's own component called
ConstraintList. I gathered the functions needed for editing and mutating
the constraints in a reusable hook and isolated the version of the list
used in the new feature strategy edit / create components into it's own
component so that the changes in layout will not affect anything else.
Ideally we should try to move towards a future where the components
don't keep internal state like this but clear boundaries and purposes
for the use.
