This PR adds feature name pattern validation to the import validation
step. When errors occur, they are rendered with all the offending
features, the pattern to match, plus the pattern's description and
example if available.
To achieve this I've added an extra method to the feature toggle service
that checks feature names without throwing errors (because catching `n`
async errors in a loop became tricky and hard to grasp). This method is
also reused in the existing feature name validation method and handles
the feature enabled chcek.
In doing so, I've also added tests to check that the pattern is applied.
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>
https://linear.app/unleash/issue/2-1130/documentation-about-multiple-project-roles
- Adds a section for the feature in the "Role-based Access control"
reference doc;
- Removes the mention that "Groups that *do* have a root role can't be
assigned to a project." which is no longer true;
- Adds a reference to multiple project roles in the "How to create and
assign custom project roles" guide;
- Fixes a wrong sentence in the "Assigning custom project roles" section
of the aforementioned guide;
---------
Co-authored-by: Thomas Heartman <thomas@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)
## About the changes
Create api token schema can either provide the field `project` or its
plural: `projects` so the joi validation makes them optional:
2be77fb55e/src/lib/schema/api-token-schema.ts (L20-L24)
This means that when returning the token, the response will either
contain `project` or `projects` depending on what was provided as input.
Therefore we need to make both fields optional in the response
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.
The error message only tells the user that the name doesn't match the
pattern. Because we already show the pattern above the input, we don't
need to repeat it in the error message. This makes for a shorter and
more concise message and better UX.
At the same time, for API users, we can keep the more detailed message
that includes info about the pattern, the example, and the description.
This change makes it so that you can save flag naming data on project
creation.
There was a mismatch between flattened and nested data in the creation
endpoint. Likely because we went back and forth a bit when we created
the feature originally.
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.
Bumps [@adobe/css-tools](https://github.com/adobe/css-tools) from 4.0.2
to 4.3.1.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/adobe/css-tools/blob/main/History.md"><code>@adobe/css-tools</code>'s
changelog</a>.</em></p>
<blockquote>
<h1>4.3.1 / 2023-03-14</h1>
<ul>
<li>Fix redos vulnerability with specific crafted css string -
CVE-2023-26364</li>
</ul>
<h1>4.3.0 / 2023-03-07</h1>
<ul>
<li>Update build tools</li>
<li>Update exports path and files</li>
</ul>
<h1>4.2.0 / 2023-02-21</h1>
<ul>
<li>Add <a
href="https://github.com/container"><code>@container</code></a>
support</li>
<li>Add <a href="https://github.com/layer"><code>@layer</code></a>
support</li>
</ul>
<h1>4.1.0 / 2023-01-25</h1>
<ul>
<li>Support ESM Modules</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/adobe/css-tools/commits">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/Unleash/unleash/network/alerts).
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
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? -->
