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.
This PR fixes a couple of issues with the pagination bar:
* Fixes an issue where padding bottom would be broken due to disabling
padding on the parent container
* Remove padding on the entire table to create more space and remove
header bar border radius as per discussion with @nicolaesocaciu
This PR makes changes to how the project overview skeleton screen works.
Important changes:
- Add skeleton screens to missing elements, creating a more
comprehensive loading screen
- Split the page into different loading sections, so that we can load
the table when we fetch the next page without affecting the rest of the
page.
https://www.loom.com/share/e5d30dc897ac488ea80cfae11ffab646
Next steps:
* Hide bar if total is less than 25
* Add FE testing
https://linear.app/unleash/issue/2-1549/ui-align-with-uiux
Includes UI/UX adjustments to the banners feature after aligning with
@nicolaesocaciu
There are a lot of changes, but here are a few:
- Redesigned preview section
- Redesigned banner status (enabled) section
- Reordered form fields to better fit the flow
- Reordered fields in the side-panel payload to reflect order in the UI
- Made inputs full width
- Adjusted multiline fields
- Added a link to Markdown's basic syntax examples
- Added a "preview dialog" button
- Updated `HelpIcon` usage to use the `htmlTooltip`
- Improved `Banner` inline design, added a maxHeight prop for usage
inside a table
- Improved `FormSwitch` design
Co-authored-by: Nicolae <nicolae@getunleash.ai>
This PR fixes a bug where the rendering in the frontend would only
render the last seen component if feature.lastSeenAt was set, the new
changes considers whether or not environments last seen at is present
and takes precedent over the legacy last seen at field.
We love all open-source Unleash users. in 2022 we built the [segment
capability](https://docs.getunleash.io/reference/segments) (v4.13) as an
enterprise feature, simplify life for our customers.
Now it is time to contribute it to the world 🌏
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
This PR fixes a bug reported from a customer where deleting a legal
value that was used in a strategy constraint would make it impossible to
edit the constraint.
[The bug was introduced
here](https://github.com/Unleash/unleash/pull/4473)
The core of the problem introduced was that the values used to calculate
illegal values was based on changing state. On the first render it would
display correct state as it would match the legal values coming from the
context definition with the legal values currently used in the
constraint as values. However, when you triggered the onClick method for
the checkboxes the state would be changed because we would remove the
illegal values from the valueset and only insert current legal values in
the state. This would trigger a re-render of the component, and now the
data used to identify the illegal values would no longer be correct,
because the bad values had been cleaned from the state. This would cause
the UI for constraints to display incorrectly.
Changed the flow to now give you a warning if you have illegal values,
and that if you make changes and save the strategy these values will be
removed from the constraint:
<img width="726" alt="Skjermbilde 2023-08-25 kl 08 56 02"
src="https://github.com/Unleash/unleash/assets/16081982/78e9875d-d864-4e21-bfb7-a530247a07eb">
Also amended this to apply to the single legal value constraints.
<img width="721" alt="Skjermbilde 2023-08-25 kl 08 57 40"
src="https://github.com/Unleash/unleash/assets/16081982/237a11d0-5c05-445c-9e99-b79cab0bff94">
https://linear.app/unleash/issue/2-1128/change-the-api-to-support-adding-multiple-roles-to-a-usergroup-on-ahttps://linear.app/unleash/issue/2-1125/be-able-to-fetch-all-roles-for-a-user-in-a-projecthttps://linear.app/unleash/issue/2-1127/adapt-the-ui-to-be-able-to-do-a-multi-select-on-role-permissions-for
- Allows assigning project roles to groups with root roles
- Implements new methods that support assigning, editing, removing and
retrieving multiple project roles in project access, along with other
auxiliary methods
- Adds new events for updating and removing assigned roles
- Adapts `useProjectApi` to new methods that use new endpoints that
support multiple roles
- Adds the `multipleRoles` feature flag that controls the possibility of
selecting multiple roles on the UI
- Adapts `ProjectAccessAssign` to support multiple role, using the new
methods
- Adds a new `MultipleRoleSelect` component that allows you to select
multiple roles based on the `RoleSelect` component
- Adapts the `RoleCell` component to support either a single role or
multiple roles
- Updates the `access.spec.ts` Cypress e2e test to reflect our new logic
- Updates `access-service.e2e.test.ts` with tests covering the multiple
roles logic and covering some corner cases
- Updates `project-service.e2e.test.ts` to adapt to the new logic,
adding a test that covers adding access with `[roles], [groups],
[users]`
- Misc refactors and boy scouting
---------
Co-authored-by: David Leek <david@getunleash.io>
Co-authored-by: Mateusz Kwasniewski <kwasniewski.mateusz@gmail.com>
Co-authored-by: Nuno Góis <github@nunogois.com>
When editing a constraint that uses a context field with legal values:
if the contraint has a value that has been deleted from the legal values
of the context field:
- Show the value and mark it as disabled
- On any change -> 'cleans'/removed the deleted legal values from the
constraint values
Closes:
[1-1209](https://linear.app/unleash/issue/1-1209/if-i-modified-the-legal-values-of-a-used-context-field)
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
Adds last seen by environment to FeatureOverview
- Refactored FeatureEnvironmentSeen component for reusability
<!-- Does it close an issue? Multiple? -->
Closes #
[1-1223](https://linear.app/unleash/issue/1-1223/toggle-overview-add-last-seen-by-environment)
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
## About the changes
Update menu for Pro customers - show enterprise options with plan
upgrade suggestion page.
Note: it doesn't work yet! It just throws an error.
This PR adds some logic to conditionally display "Add to draft" button
for segments if the segment is part of a project that has change
requests enabled and the flag is enabled.
Also adds a flag (`segmentChangeRequests`) to the frontend.
Holding off on actually adding the change to a draft until the API/orval
has been updated with the most recent changes.
https://linear.app/unleash/issue/2-1171/refactor-custom-root-roles-with-correct-plan-assumptions
This cleans up the hotfix `RoleSelect2` component and makes `RoleSelect`
take in a `roles` prop from the parent component.
This also simplifies the role hooks again to assume Enterprise plan by
default. This means, however, that we must ensure that we only call
these hooks in Enterprise features or, if we do call them in other
plans, that we provide a graceful fallback for non-Enterprise.
Non-Enterprise instances do not have this endpoint, and so they are
currently grabbing role information from e.g. `useUsers` and
`useServiceAccounts`.
I'm not sure how I feel about this. Roles are an overarching concept of
Unleash. To me, having to be extremely conscious about the exact
scenario in which you're using such a hook feels like a trap, instead of
"I need roles, so I'll grab the `useRoles` hook and not think much about
it". I also don't like the way `roles` are currently tied to the users,
service accounts, project access, (...) instead of being its own thing.
This could be solved by a `RoleController` exposing the GET endpoints in
OSS, since all of the logic we need for this use-case lives there
anyways. This would then be overridden with the Enterprise-specific
controller when wrapped. This way we could assume the endpoint is always
there, no matter the plan.
This is just an idea and not something I explored in the PR. For now I'm
just focusing on leaving this feature in a sane state.
Tested this manually on `Pro` and `Enterprise` and I believe everything
is acting the way we intend, but would love some extra eyes.
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
Remove strategy improvements flag
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Closes #
[1-1048](https://linear.app/unleash/issue/1-1048/remove-strategyimprovements-flag)
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
## About the changes
This PR enables or disables create API token button based on the
permissions.
**Note:** the button is only displayed if you have READ permissions on
some API token. This is a minor limitation as having CREATE permissions
should also grant READ permissions, but right now this is up to the user
to set up the custom role with the correct permissions
**Note 2:** Project-specific API tokens are also ruled by the
project-specific permission to create API tokens in a project (just
having the root permissions to create a client token or frontend token
does not grant access to create a project-specific API token). The
permissions to access the creation of a project-specific API token then
rely on the root permissions to allow the user to create either a client
token or a frontend token.
---------
Co-authored-by: David Leek <david@getunleash.io>
https://linear.app/unleash/issue/2-1137/roles-unification-on-the-ui
Root and project roles should be managed in a similar manner, which
means using the same roles route and tab for both.
Additionally, this includes a big revamp to the project roles to align
them more closely with the modern and standardized custom root roles
that were recently developed. They mostly use the same components.
There are still more things we want to improve and unify, but we've left
some of that out of this PR due to PR size concerns.
https://linear.app/unleash/issue/2-1135/address-3975-pr-comments-by-refactoring-some-of-the-new-custom-root
This pull request addresses the majority of the comments raised in issue
#3975 and lays the groundwork for unifying roles. The idea is for
project roles to also be managed in the "Roles" tab, and several
components, such as `RoleForm` and the `useRoleForm` can potentially be
reused.
I'll leave the further investigation and implementation of unifying
roles to be addressed in a separate task.
As a mostly unrelated UI fix, this also adds an arrow to the tooltip in
the `RoleBadge` component.
