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.
