Adds `number` as possible payload type for variant.
Adds a flag to enable the feature
Updates all relevant models and schemas
Adds the option to the UI
Closes: #
[1-1357](https://linear.app/unleash/issue/1-1357/support-number-in-variant-payload)
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
## About the changes
Instead of this:
```ts
const { uiConfig } = useUiConfig();
const myFlag = Boolean(uiConfig?.flags?.myFlag)
```
we can have this:
```ts
const myFlag = useUiFlag("myFlag")
```
With the same type safety, less verbose and more purposeful code.
### Important files
- `frontend/src/hooks/useUiFlag.ts`
## Discussion points
Can we in the future share flags between frontend and backend? Right now
adding a new flag has to be done in 4 different places (backend flag
keys list, backend flags defaults config, backend experimental server
options, frontend type).
Most ergonomic option is to pull config directly from Unleash.
Issue, based on previous user feedback:
https://github.com/Unleash/unleash/issues/4565
Internal feature request document:
[docs.google.com/document/d/1Sx0q...](https://docs.google.com/document/d/1Sx0qKZXUVUCjuY5F4MOh1ieOM1A2_jE58zEA7jaM_1g/edit?usp=sharing)
Because you need to match the pattern when copying toggles, it's
important that we show the required information to the user.
This change adds information about the pattern to the page. This isn't
its final design, but it's more important that the information is
there (to avoid user frustration) than that it is pretty.
This change makes it so that the flag name is revalidated against the
new
project pattern whenever you change the target project for a flag.
The validation is not run if the name is empty, if there is no
pattern, or if there is no validation method.
This solves the case where you input a name, then change the project,
and where the name isn't valid for the new project. Previously, it
wouldn't revalidate, but now it does.
While having a pattern when you have no example doesn't make a lot of
sense, it's a problem that you can't delete the example after deleting
the pattern: you previously had to remove the example before the
pattern.
This PR fixes that by always allowing you to update the example, even if
there is no pattern. Our server doesn't currently accept submitting an
example with no pattern, but we could allow that if we want to (and
probably just discard it on the back-end).
This PR also updates the validation of the example and the regex. There
were more unhandled edge cases previously where the validation would
disappear or be wrong. This should be fixed now. The new logic is that,
whenever you update the either the pattern or the example, we check:
- if you have an error in your pattern, no pattern, or no example, then
delete the example error if it exists
- have a well-formed pattern and an example then check if the example
matches the pattern and add/delete an error accordingly
This does have some consequences: editing the pattern can render your
example invalid. You'll also get immediate feedback instead of when you
switch focus. I think this is often a bad pattern (giving the user too
much negative feedback), but in terms of working with regexes, I think
it might be a good thing. We also give immediate feedback today, so I
don't think this is a regression.
Any thoughts are welcome.
Since `auth/{auth_type}/settings` is an Enterprise route, this prevents
404s when we try to use the hook to fetch auth settings in
non-Enterprise instances by using the conditional `useEnterpriseSWR`
hook.
This PR adds a feature naming pattern description to the project form.
It's rendered as a multi-line input field. The description is also
stored in the db.
This adapts most of @andreas-unleash's PR #4599 with some minor changes
(using description instead of prompt). Actually displaying this data to
the users will come in a later PR.
Does what it says on the tin, should help with cleaning up
https://github.com/Unleash/unleash/pull/4512 and respective schema
changes.
---------
Co-authored-by: Gastón Fournier <gaston@getunleash.io>
## 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 #
<!-- (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? -->
<!-- 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
When archiving or reviving feature toggles, when toggles disappear from
table, actions bar should also disappear.
<!-- Does it close an issue? Multiple? -->
Closes
https://linear.app/unleash/issue/1-1293/bulk-revive-modal-doesnt-go-away
Adds a first iteration of feature flag naming patterns. Currently behind a flag.
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
Co-authored-by: andreas-unleash <andreas@getunleash.ai>
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
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>
## 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. -->
Adds projects user and group -usage information to the dialog shown when
user wants to delete a project role
<img width="670" alt="Skjermbilde 2023-08-10 kl 08 28 40"
src="https://github.com/Unleash/unleash/assets/707867/a1df961b-2d0f-419d-b9bf-fedef896a84e">
---------
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>
https://linear.app/unleash/issue/2-1136/custom-root-roles-documentation
- [Adds documentation referencing custom root
roles](https://unleash-docs-git-docs-custom-root-roles-unleash-team.vercel.app/reference/rbac);
- [Adds a "How to create and assign custom root roles" how-to
guide](https://unleash-docs-git-docs-custom-root-roles-unleash-team.vercel.app/how-to/how-to-create-and-assign-custom-root-roles);
- Standardizes "global" roles to "root" roles;
- Standardizes "standard" roles to "predefined" roles to better reflect
their behavior and what is shown in our UI;
- Updates predefined role descriptions and makes them consistent;
- Updates the side panel description of the user form;
- Includes some boy scouting with some tiny fixes of things identified
along the way (e.g. the role form was persisting old data when closed
and re-opened);
Questions:
- Is it worth expanding the "Assigning custom root roles" section in the
"How to create and assign custom root roles" guide to include the steps
for assigning a root role for each entity (user, service account,
group)?
- Should this PR include an update to the existing "How to create and
assign custom project roles" guide? We've since updated the UI;
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
This change addresses two things that were done in
https://github.com/Unleash/unleash/pull/4004 and that I believe to be
bugs.
1. It shows the previous strategy name also if there was no previous
title. So if there was no previous title, it'll show the strategy name
with a strikethrough and then the new title (see the discussion
section).
2. It changes a `span` component to a [`del`
component](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/del).
I believe the
span was erroneously changed from a `s` component (strikethrough
component) in the linked PR (based on a comment on the PR). This
caused the strikethrough to not be there anymore. However, the `del`
component is semantically more correct and reintroduces the
strikethrough, so it is a better change.
3. It uses [`ins`
elements](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ins)
for names that have changed.
Finally, it removes a redundant pair of curly braces.
How it looks now:
## Discussion
Regarding point 1: It might be that we don't want to show a
strikethrough through the name of the strategy if there was no previous
title. In that case, the changes related to the first point should be
removed. If we do that, it looks like this:
It makes it harder (impossible, actually) to see when a custom title was
added, but that might be what we want.
But maybe the solution is to also use `ins` elements for new data. That
way the difference is visible (and semantically correct):
<!-- 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>
