fix: broken UI when importing features into environments which are not linked to the feature's project
## Related to
- PR: https://github.com/Unleash/unleash/pull/2209
- Issue: https://github.com/Unleash/unleash/issues/2186
- Issue: https://github.com/Unleash/unleash/issues/2193
## Expected behaviour:
After importing we should see:
## About the changes
**The problem:** when we import we have projects, features and
environments. Each feature belongs to a project (this is by default and
the imported file enforces that). The links between projects and
features, or projects and environments, depend on us creating those
relationships. When we add a feature to an environment we're not
validating that the project and the environment are connected. Because
of that, in some situations (like in this test), we can end up with a
project with features but no environment.
This breaks a weak constraint we had which is that all projects should
have at least one environment.
**This PR makes the following assumption when importing**: _if a feature
is added to an environment, and that environment is still not linked to
the project that feature belongs to, then the project and environments
have to be linked_. The rationale behind this is that the user couldn't
have generated this export file without the project and environment
being linked together.
<!-- 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! ❤️ -->
This PR sets up exports so that we can import in enterprise with just
"unleash-server".
This will free us to refactor unleash internals without breaking
enterprise
## 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? -->
This PR adds implements the frontend and migrations part of multiple
reviewers.
2 UI parts:
1. Configuration to add the count of required approvals
2. Handle multiple approvers in review page.
<!-- 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! ❤️ -->
Add change_request_settings table
Remove change_request_enabled column
## 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? -->
## What
This change removes the use of double quotes in the
'addPublicSignupTokenUser' endpoint summary. It also changes the
original summary to a description and adds a new, shorter summary.
## Why
The OpenAPI / docusaurus integration errors out (refer to [this failed
build](https://github.com/Unleash/unleash/actions/runs/3434792557/jobs/5726445104))
if the frontmatter contains invalid characters. In this case, it's
because the automatic sidebar label contains double quotes, which it
interprets as a new key having been declared:
```
Error: Error while parsing Markdown front matter.
This can happen if you use special characters in front matter values (try using double quotes around that value).
Error: Loading of version failed for version current
Error: Unable to build website for locale en.
Error: YAMLException: can not read a block mapping entry; a multiline key may not be an implicit key at line 4, column 12:
description: "Create a user with the 'viewe ...
^
```
For some reason, I cannot reproduce this error locally. Instead, the
generation goes as expected.
---
Regarding using description instead of summary: summaries should be very
short and sweet, especially because they're also used in the generated
sidebar. Descriptions can be a bit wordier, so I added a shorter summary
for going forward.
## Generated output
This is what the old configuration would generate. Notice the
`sidedar_label` key on line 2:
```md
---
id: add-public-signup-token-user
sidebar_label: Create a user with the "viewer" root role and link them to a signup token
hide_title: true
hide_table_of_contents: true
api: {'tags': ['Public signup tokens'], 'operationId': 'addPublicSignupTokenUser', 'requestBody': {'description': 'createInvitedUserSchema', 'required': true, 'content': {'application/json': {'schema': {'type': 'object', 'additionalProperties': false, 'required': ['email', 'name', 'password'], 'properties': {'username': { 'type': 'string' }, 'email': { 'type': 'string' }, 'name': { 'type': 'string' }, 'password': { 'type': 'string' },},},},},}, 'responses': {'200': {'description': 'userSchema', 'content': {'application/json': {'schema': {'type': 'object', 'additionalProperties': false, 'required': ['id'], 'properties': {'id': {'type': 'number',}, 'isAPI': {'type': 'boolean',}, 'name': {'type': 'string',}, 'email': {'type': 'string',}, 'username': {'type': 'string',}, 'imageUrl': {'type': 'string',}, 'inviteLink': {'type': 'string',}, 'loginAttempts': {'type': 'number',}, 'emailSent': {'type': 'boolean',}, 'rootRole': {'type': 'number',}, 'seenAt': {'type': 'string', 'format': 'date-time', 'nullable': true,}, 'createdAt': {'type': 'string', 'format': 'date-time',},},},},},}, '400': {'description': 'The request data does not match what we expect.',}, '409': {'description': 'The provided resource can not be created or updated because it would conflict with the current state of the resource or with an already existing resource, respectively.',},}, 'parameters': [{'name': 'token', 'in': 'path', 'required': true, 'schema': { 'type': 'string' },},], 'description': 'Create a user with the "viewer" root role and link them to a signup token', 'method': 'post', 'path': '/invite/{token}/signup', 'servers': [{ 'url': '<your-unleash-url>' }], 'security': [{ 'apiKey': [] }], 'securitySchemes': {'apiKey': {'type': 'apiKey', 'in': 'header', 'name': 'Authorization',},}, 'jsonRequestBodyExample': {'username': 'string', 'email': 'string', 'name': 'string', 'password': 'string',}, 'info': { 'title': 'Unleash API', 'version': '4.17.2' }, 'postman': {'name': 'Create a user with the "viewer" root role and link them to a signup token', 'description': { 'type': 'text/plain' }, 'url': {'path': ['invite', ':token', 'signup'], 'host': ['{{baseUrl}}'], 'query': [], 'variable': [{'disabled': false, 'description': {'content': '(Required) ', 'type': 'text/plain',}, 'type': 'any', 'value': '', 'key': 'token',},],}, 'header': [{ 'key': 'Content-Type', 'value': 'application/json' }, { 'key': 'Accept', 'value': 'application/json' },], 'method': 'POST', 'body': {'mode': 'raw', 'raw': '""', 'options': { 'raw': { 'language': 'json' } }}}}
sidebar_class_name: 'post api-method'
info_path: docs/reference/api/unleash/unleash-api
---
import ApiTabs from "@theme/ApiTabs"; import MimeTabs from "@theme/MimeTabs"; import ParamsItem from "@theme/ParamsItem"; import ResponseSamples from "@theme/ResponseSamples"; import SchemaItem from "@theme/SchemaItem" import SchemaTabs from "@theme/SchemaTabs"; import DiscriminatorTabs from "@theme/DiscriminatorTabs"; import TabItem from "@theme/TabItem";
## Create a user with the "viewer" root role and link them to a signup token
Create a user with the "viewer" root role and link them to a signup token
<!-- And much much more! -->
```
<!-- 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! ❤️ -->
- Add `change_request_enabled` column to `projects` and
`project_environments`
- Modified the store to include the new column
- Added new column to Project open api schema
## 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? -->
1. Added database table for change request approvals
2. Removed separate endpoint for applying. **Now all state changes will
go through same endpoint.**
From Thomas and mine testing. BaseUriPath can't be set as an environment
variable because we override it when trying to format the URI from the
server config. This PR makes sure we only format if the custom server
options actually have baseUriPath set.
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
## What
This PR updates the `paramToBool` function to first check whether the
incoming argument is a boolean. This fixes the bug where using `true` or
`false` (e.g. `Strategies=false`) in the query would cause the server to
crash.
I've also added a test case to check for these values.
## Why
While working on the import/export API docs, I noticed that using
`false` in an export request caused the server to crash.
As we want to allow `true` and `false` (and use these values in the
documentation), we should ensure that they work as expected.
## Background
It's likely that this bug was introduced when we added the new OpenAPI
query parameters to the export endpoint. Because of the way that the
OpenAPI service we use does conversion, we now get `true` and `false`
converted to actual boolean values instead of strings. The `paramToBool`
function didn't account for that previously, which is why it caused the
server to crash.
## What
This PR fixes a bug where fetching a feature toggle via the
`/api/admin/projects/:projectId/features/:featureName` endpoint doesn't
validate that the feature belongs to the provided project. The same
thing applies to the archive functionality. This has also been fixed.
In doing so, it also adds corresponding tests to check for edge cases,
updates the 403 error response we use to provide clearer steps for the
user, and adds more error responses to the OpenAPI documentation.
## Why
As mentioned in #2337, it's unexpected that the provided project
shouldn't matter at all, and after discussions internally, it was also
discovered that this was never intended to be the case.
## Discussion points
It might be worth rethinking this for Unleash v5. Why does the features
API need the projects part at all when features are unique across the
entire instance? Would it be worth reverting to a simpler feature API
later or would that introduce issues with regards to how different
projects can have different active environments and so on?
### Further improvements
I have _not_ provided schemas for the error responses for the endpoints
at this time. I considered it, but because it would introduce new schema
code, more tests, etc, I decided to leave it for later. There's a
thorough OpenAPI walkthrough coming up, so I think it makes sense to do
it as part of that work instead. I am happy to be challenged on this,
however, and will implement it if you think it's better.
### Why 403 when the project is wrong?
We could also have used the 404 status code for when the feature exists
but doesn't belong to this project, but this would require more (and
more complex) code. We also already use 403 for cases like this for
post, patch, and put. Finally, the [HTTP spec's section on the 403
status code](https://httpwg.org/specs/rfc9110.html#status.403) says the
following (emphasis mine):
> The 403 (Forbidden) status code indicates that the server
**_understood the request but refuses to fulfill it_**. A server that
wishes to make public why the request has been forbidden can describe
that reason in the response content (if any).
>
> If authentication credentials were provided in the request, the server
considers them insufficient to grant access. The client SHOULD NOT
automatically repeat the request with the same credentials. The client
MAY repeat the request with new or different credentials. However, **_a
request might be forbidden for reasons unrelated to the credentials_**.
As such, I think using 403 makes sense in this case.
---
Closes#2337.
* Fixes a memory leak where events would trigger the data polling to restart. Any event would setup another polling interval, which would strain our database. Separated the logic for fetching the data and the polling, and made sure that the polling was only initialized once.
* fix: limit total of PATs a user can have
* increase PAT limit to 10
* Update src/lib/services/pat-service.ts
Co-authored-by: Simon Hornby <liquidwicked64@gmail.com>
* disable button on the front-end when PAT limit is reached
* import from server instead of repeating ourselves
Co-authored-by: Simon Hornby <liquidwicked64@gmail.com>
* OpenAPI(feat): add new 'Segments' tag
## What
This change adds a new Segments tag to the list of valid OpenAPI tags.
## Why
When updating tags for the enterprise version of Unleash, I realized
we didn't have any tags that were appropriate for the segments
endpoints.
* chore: Update snapshot
* Add suggest-change-store.ts and db migration
* Add suggest-change-store.ts and db migration
* change payload and event data type
* Update src/lib/db/suggest-change-store.ts
Co-authored-by: Fredrik Strand Oseberg <fredrik.no@gmail.com>
* split to 3 tables, create event on every change
* split to 3 tables, create event on every change
* Move service to enterprise
PR Comments
* PR Comments
* replacy createdBy string with User
* replace createdBy string with User
* added event to docs
* return entire changeset after adding a change
* bug fix
* bug fix
* move add change return to service layer
* PR comments
* added user id to user objects
* added user id to user objects
* added user id to user objects
* bug fix
* Rework
* Remove event and fix queries
* Update snapshot
* Remove console logs
* Fix
Co-authored-by: Fredrik Strand Oseberg <fredrik.no@gmail.com>
Co-authored-by: sjaanus <sellinjaanus@gmail.com>
