## About the changes
1. Create tag should not throw a 500 when bad data is provided
2. Added summary, description and examples to open API endpoints
---------
Co-authored-by: Nuno Góis <github@nunogois.com>
<!-- 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! ❤️ -->
Changes the schema and api to accept any string for defaultStickiness
## 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? -->
---------
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
<!-- 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? -->
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
## About the changes
- Refactored some E2E tests to use our APIs
- Added test cases for project-specific segments
- Added validation to check a project can access a specific segment
- Fixed an OpenAPI schema that was missing segments
## Discussion points
https://github.com/Unleash/unleash/pull/3339/files#r1140008992
This PR changes how we calculate average time to production. Instead of
calculating fleeting 30 day windows and calculating the past and current
window, we now calculate a flat average across the entire project life.
This is less error prone as each feature will be tied to the earliest
time it was turned on in a production environment.
<!-- 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 replaces localStorage with api calls for getting/setting project
scoped stickiness
## 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? -->
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
## About the changes
- Introducing ISegmentService interface to decouple from the actual
implementation
- Moving UpsertSegmentSchema to OSS to be able to use types
- Added comments where our code is coupled with segments just to
highlight and have a conversation about some use cases if needed, but
they can be removed before merging
- Removed segment service from some project features as it was not used
<!-- 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! ❤️ -->
Introduces 2 new endpoints (behind flag `projectScopedStickiness` to set
and get the setting
## 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? -->
---------
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! ❤️ -->
- Create UpdateTagsSchema
- Create PUT endpoint
## 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? -->
Relates to#
https://linear.app/unleash/issue/1-767/refactor-existing-tag-component-to-also-allow-removing-tags
<!-- (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
Add new methods to simplify the creation of schemas for endpoints with
additional media types (other than `application/json`)
This is a follow-up on exporting an endpoint as `text/csv`
## About the changes
client-metrics-schema is less strict than proxy-metrics-schema because
the former allows empty `instanceId` and also supports dates as
timestamps as well as date-formatted strings.
Using the same schema makes sense to reduce maintainability costs and
it's less error-prone if we need to modify the schema because underlying
the schema they both use the same code.
The reasoning is that proxy metrics should align with our client
metrics. Alternatively, we have new endpoints for edge metrics that will
aggregate and bucket by client.
## Discussion points
Will we ever want to evolve proxy-metrics differently than
client-metrics? I'm under the assumption that the answer is no
### What
Change /edge/metrics endpoint to accept list of ClientMetricsEnv
### Rationale
We originally made the assumption that we probably didn't need to keep
splitting from a map of features into ClientMetricsEnv for bulk, instead
the bulk poster could post ClientMetricsEnv directly. However, Unleash
still expected the old client metrics format with a dictionary of
featurename -> metricsForFeature. This PR changes that to now accept the
list of ClientMetricsEnv (preprocessed data from downstream) instead of
expecting metrics to be in the old single application metric format.
## About the changes
Promoted experimental networkView flag into a configuration that relies
on prometheusApi being configured.
Also, a follow-up on https://github.com/Unleash/unleash/pull/3054 moving
this code to enterprise because it doesn't make sense to maintain this
code in OSS where it's not being used.
## About the changes
Implementation of bulk metrics and registration endpoint. This will be
used by edge nodes to send all collected information.
Types around metrics were improved and `IClientApp.bucket` with type
`any` is no longer needed
---------
Co-authored-by: sighphyre <liquidwicked64@gmail.com>
## About the changes
This PR prepares the GA of service accounts: OpenAPI tags, documentation
and flag removal
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#2942
---------
Co-authored-by: Nuno Góis <github@nunogois.com>
## About the changes
Add warnings when we detect something might be wrong with the customer
configuration, in particular with regard to variants configuration
## Rationale
Moving from variants per feature to variants per environment will allow
users to have fine-grained permissions and more control over variants on
different environments: #2254
But because this requires an additional step of copying variants to
other environments, we identified the potential risk of users forgetting
to follow this step. To keep them informed about this, we're introducing
a warning sign after a toggle is enabled when we detect that:
1. The environment is enabled without variants
2. Other enabled environments have variants
This situation would be a problem if you rely on `getVariant` method
from the SDK, because without variants you'll receive the default
variant. Probably, not what you'd expect after enabling the toggle, but
there are situations where this might be correct. Because of the latter,
we thought that adding a warning and letting the user handle the
situation was the best solution.
## UI sketches
Co-authored-by: Nuno Góis <github@nunogois.com>
## About the changes
This PR adds the ability to push variants to multiple environments
overriding the existing variants.
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#2254
**Note:** This won't fail if there are variants in other environments, because the operation wouldn't be idempotent. It should have that property because setting variants to 1 or more environments once or twice should not make a difference
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! ❤️ -->
This PR fixes the admin feature schema by moving the `strategies`
(featureStrategySchema) from the root of `feature` object to
`feature.environment`
## 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? -->
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
## About the changes
This PR improves our queries to Prometheus (instead of making multiple queries do only one) and improves the UI and the code.
The reports aggregate all HTTP methods (GET, POST, PUT, DELETE, OPTIONS, HEAD and PATCH) without distinction under the same "endpoint" (a relative path inside unleash up to a certain depth)
Co-authored-by: Nuno Góis <nuno@getunleash.ai>
## About the changes
The deprecated /api/admin/features endpoint supported querying with tag
and namePrefix parameters.
This PR adds this functionality to
/api/admin/projects/<project>/features as well, allowing to replicate
queries that used to work.
Closes#2306
### Important files
src/lib/db/feature-strategy-store.ts
src/test/e2e/stores/feature-strategies-store.e2e.test.ts
## Discussion points
I'm extending our query parameters support for
/api/admin/projects/<projectId>/features endpoint. This will be
reflected in our open-api spec, so I also made an
adminFeaturesQuerySchema for this.
Also, very open for something similar to what we did for the modifyQuery
for the archived parameter, but couldn't come up with a good way to
support subselects using the query builder, it just ended up blowing the
stack. If anyone has a suggestion, I'm all ears.
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
## About the changes
This connects our backend with Prometheus (or compatible) metrics
service, and exposes raw data (i.e. acting as a proxy)
Co-authored-by: Christopher Kolstad <chriswk@getunleash.ai>
Adds ability to favorite projects.
1. Can favorite project
2. Can unfavorite project
3. Favorite field is returned on `/api/admin/projects/default`
4. Favorite field is returned on` /api/admin/projects`
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
<!-- 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? -->
## 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? -->
* 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
* fixed segments not being copied
* fix fmt
* bug fix
* return segmentId[] when getting a feature strategy
* do not return segments if they are not there
* Update src/lib/services/feature-toggle-service.ts
Co-authored-by: Fredrik Strand Oseberg <fredrik.no@gmail.com>
* fix lint
* fix: more explicit column sorting and bug fix
* update snapshot
* rollback
* add segment ids to feature strategies
* bug fix
Co-authored-by: Fredrik Strand Oseberg <fredrik.no@gmail.com>
## What
This PR does two things:
1. Add tests to ensure that all OpenAPI tags are listed in the root-level `tags` property of the spec.
2. Changes the tags for endpoints that use any of the deprecated tags (specifically `admin`).
## Why
When we moved to using the docusaurus OpenAPI doc generator, we made some changes to existing tags. Moving away from having just 'admin', 'client', and one or two more, we now use a more granular system, which makes it easier to find an endpoint by category.
However, there's currently nothing enforcing this and this bit of knowledge hasn't been clearly communicated to anyone. Because of this, we have some endpoints that are currently just grouped under a general 'admin' tag.
This has two drawbacks:
- In Swagger UI, all these endpoints are grouped together. This means that they break with the expectation that each endpoint has its own category. Further, being lumped together means that the 'admin' group is hard to read.
- The 'admin' tag is (on purpose) not included in the root-level `tags` property of the generated OpenAPI spec. This means that the OpenAPI docusaurus generator doesn't pick up those endpoints, which means that they're not included in the docs on docs.getunleash.io.
## How
By implementing tests that:
1. Check that the tags included in the spec are a subset of the "approved" tags
2. By checking each path in the OpenAPI spec and making sure that all its tags are listed in the root-level tag list. If this is not the case, the test fails and it logs an error explaining what is wrong to the console. An example of such a message is:
```
The OpenAPI spec contains path-level tags that are not listed in the root-level tags object. The relevant paths, operation ids, and tags are as follows:
POST /api/admin/feedback (operation id: createFeedback) has the following invalid tags: "admin"
PUT /api/admin/feedback/{id} (operation id: updateFeedback) has the following invalid tags: "admin"
For reference, the root-level tags are: "Addons", "Admin UI", "API tokens", "Archive", "Auth", "Client", "Context", "Edge", "Environments", "Events", "Features", "Import/Export", "Metrics", "Operational", "Playground", "Projects", "Public signup tokens", "Strategies", "Tags", "Unstable", "Users"
```
## Commits
* fix: ensure that all root-level tags in the spec are 'approved tags'
* fix: test that all listed path tags exist in the root-level tags
* fix: use "API tokens" tag for PAT endpoints
* fix: add comment explaining why tags test is there
* fix: Update snapshot
* fix: ensure that spec tags are a subset of the approved Tags
* fix: improve error message when tags don't match
* fix: further tweaks in log format
* refactor: user creation screen cleanup
* feat: deprecation notice for google sso
* fix: docs openid typo
* invite link bar
* invite link page
* fix prettier docs
* regenerated openapi
* hooks for invite page api
* update openapi
* feat: invite link update
* feat: add public signup token soft-delete
* public signup frontend feature flag
* fix: new user api issues
* feat: allow for creating new user from invite link
* Feat/invite user public controller (#2106)
* added PublicInviteController for public urls
* added PublicInviteController for public urls
* added PublicInviteController for public urls
* added PublicInviteController for public urls
* fix test
* fix test
* update openapi
* refactor: password reset props
* fix: public invite schema and validation
Co-authored-by: Fredrik Strand Oseberg <fredrik.no@gmail.com>
* user invite frontend
Co-authored-by: Fredrik Strand Oseberg <fredrik.no@gmail.com>
* invite link delete confirmation dialog
* refactor: password reset action
* fix: new user invite loading state
* fix: run ts check with ci
* revert openapi changes
* fix: invite token api interface
* fix: openapi schema index
* fix: update test snapshots
* update frontend snapshot
* fix: prettier ci
* fix: updates after review
Co-authored-by: andreas-unleash <104830839+andreas-unleash@users.noreply.github.com>
Co-authored-by: Fredrik Strand Oseberg <fredrik.no@gmail.com>
* bug fix
* bug fix
* remove doc file
* store fixes
* bug fix
* rollback deleted file
* fix test
* add url to token
* return all tokens not just active
* add url fix
* PR comment
* PR comment
* PR comment
* add the flag to the experimental options
* fix env var name
## What
This change reverts the spec change to create-api-token-schema that
was introduced in 97c2b3c089
That commit changed the endpoint from allowing any string to only
allowing strings that match the values of the ApiTokenType value.
## Why
Because we already validate this on the backend, I didn't think it
would break anything. However, because OpenAPI enums are case
sensitive (and do not currently support anything else), it _did_ break
the API. ([stack overflow post that explains how this
works](https://stackoverflow.com/questions/60772786/case-insensitive-string-parameter-in-schema-of-openapi))
## Of note
This should have been caught by the tests, but it didn't show up until
it was merged to the main branch. I think it might be worth looking
into how we do the PR testing.
## What
This PR adds an extra layer of OpenAPI validation testing to what we already have. It also fixes any issues that make the new tests fail.
## Why
While the current OpenAPI validation takes care of _some_ things, there's also things it misses, as shown by #2055. By adding the OpenAPI Enforcer package, we should hopefully be able to catch more of these errors in the future. The enforcer _does_ flag the issue in #2055 as an error.
## How
By adding the OpenAPI Enforcer package and making whatever changes it picks up on.
By adding location headers to all our 201 endpoints. I also had to change some signatures on `create` store methods so that they actually return something (a lot of them just returned `void`).
## Discussion points
### Code changes
Some of the code changes may not be necessary or we may want to change more code to align with what changes have been done. It may be worth standardizing on a pattern for `*store.create` methods, so that they always return an identifier or the stored object, for instance.
### On relative URIs
The 201 location headers use relative URIs to point to the created resources. This seemed to be the easiest way to me, as we don't need to worry about figuring out what the absolute URL of the instance is (though we could probably just concat it to the request URI?). The algorithm for determining relative URIs is described in [RFC 3986 section 5](https://www.rfc-editor.org/rfc/rfc3986#section-5).
There's also some places where I'm not sure we _can_ provide accurate location url. I think they're supposed to point _directly at_ whatever the resource is, but for some resources (such as api tokens), you can only get it as part of a collection. From [RFC 9110 on the location field](https://httpwg.org/specs/rfc9110.html#field.location) (emphasis mine):
> the Location header field in a [201 (Created)](https://httpwg.org/specs/rfc9110.html#status.201) response is supposed to provide a URI that is **specific** to the created resource.
A link to a collection is not specific. I'm not sure what best to do about this.
### Inline comments
I've added a number of inline PR comments that I'd love to get some feedback on too. Have a look and let me know what you think!
### Unfinished business
I've added some juicy comments to some of the files here. They contain non-blocking issues that I'm tracking (via github issues). We should resolve them in the future, but right now they can stay as they are.
## Commits
* Feat: add openapi-enforcer + tests; fix _some_ issues
* Test: allow non-standard string formats
* validation: fix _some_ 201 created location header endpoints
* #1391: fix remaining 201 location headers missing
* Refactor: use the ajv options object instead of add* methods
* #1391: flag validation errors and warnings as test failures
* #1391: modify patch schema to specify either object or array
We don't provide many patch endpoints, so we _could_ create separate
patch operation objects for each one. I think that makes sense to do
as part of the larger cleanup. For now, I think it's worth to simply
turn it into one of these. While it's not entirely accurate, it's
better than what we had before.
* Refactor: make tests easier to read
* #1391: use enum for valid token types
This was previously only a description. This may seem like a breaking
change because OpenAPI would previously accept any string. However,
Joi also performs validation on this, so invalid values wouldn't work
previously either.
* #1391: Comment out default parameter values for now
This isn't the _right_ way, but it's the pragmatic solution. It's not
a big deal and this works as a stopgap solution.
* #1391: add todo note for api token schema fixes
* #1391: update snapshot
* Revert "#1391: modify patch schema to specify either object or array"
This reverts commit 0dd5d0faa1.
Turns out we need to allow much more than just objects and arrays.
I'll leave this as is for now.
* Chore(#1391): update comment explaining api token schema TODO
* #1391: modify some test code and add comment
* #1391: update tests and spec to allow 'any' type in schema
* Chore: remove comment
* #1391: add tests for context field stores
* #1391: add location header for public signup links
* #1391: fix query parameter description.
There was indeed a bug in the package, and this has been addressed
now, so we can go back to describing the params properly.
* First version ready
* Final
* Refactor
* Update pat store
* Website revert
* Website revert
* Update
* Revert website
* Revert docs to main
* Revert docs to main
* Fix eslint
* Test
* Fix table name
* Fix(#1391): Expose API version even when not running via npm/yarn
## What
Expose the current Unleash version in the generated OpenAPI docs, even
when running via docker or other processes.
## Why
An OpenAPI spec without a version isn't valid. This causes some of our
generation tools (such as the one for documentation) to fail.
## How
By changing how we fetch the current version:
Previously, we used `process.env.npm_package_version!`. However, when
you're not running with yarn or npm, this is `undefined`. That causes
the version number to not be included when running tests and when
running using the official docker image.
Instead, we now use `version` from `lib/util/version`. This is the
same version as the one used by the UI config endpoint, so it should
be the same one as what the front end displays. To the best of my
knowledge, this _is_ the version of the API.
## Discussion
It _may_ be that I have misunderstood what the version represents, but
from what I can tell, it just exports what's listed as the version in
package.json.
The source code of the `lib/util/version` file is:
```ts
// export module version
require('pkginfo')(module, 'version');
const { version } = module.exports;
export default version;
module.exports = version;
```
* Refactor(#1391): rename imported variable for clarity
* PublicSignupTokens
* bug fix
* bug fixes and test
* bug fixes and test
* bug fixes and test
* Add feature flag
* tests
* tests
* Update 20220908093515-add-public-signup-tokens.js
Bug Fix
* task: use swc instead of ts-jest (#2042)
* Add a counter for total number of environments (#1964)
* add groupId to gradual rollout template (#2045)
* add groupId to gradual rollout template
* FMT
* Improve tabs UI on smaller devices (#2014)
* Improve tabs UI on smaller devices
* Improve tabs UI on smaller devices
* bug fix
* add proper scrollable tabs
* removed centered from Tabs (conflicts with scrollable)
* PR comments
* 4.15.0-beta.10
* Fix broken doc links (#2046)
## What
This PR fixes some broken links that have been hanging around in the
docs for what seems like a very long time.
## Why
As discovered by the link check in #1912, there are a fair few broken
links in the docs. Everyone hates broken links because it makes it
harder to understand what they were supposed to be pointing at.
## How
There are 3 types of links that have been fixed:
- Links that should have been internal but were absolute. E.g.
`https://docs.getunleash.io/path/article` that should have been
`./article.md`
- External links that have changed, such as Slack's API description
- GitHub links to files that either no longer exist or that have been
moved. These links generally pointed to `master`/`main`, meaning
they are subject to change. They have been replaced with permalinks
pointing to specific commits.
-----
* docs: fix slack api doc link
* docs: update links in migration guide
* docs: fix broken link to ancient feature schema validation
* docs: update links to v3 auth hooks
* docs: update broken link in the go sdk article
* Fix: use permalink for GitHub link
* docs: fix wrong google auth link
* 4.15.0
* 4.15.1
* docs: update link for symfony sdk (#2048)
The doc link appears to have pointed at an address that is no longer reachable. Instead, let's point to the equivalent GitHub link
Relates to and closes#2047
* docs: test broken links in website (#1912)
The action triggers manually as a first step to test this functionality. In the near future, we might schedule it
* Schedule link checker action (#2050)
Runs at 12:30 UTC on Mon, Tue, Wed, Thu and Fri
* fix: add env and project labels to feature updated metrics. (#2043)
* Revert workflow (#2051)
* update snapshot
* PR comments
* Added Events and tests
* Throw error if token not found
Co-authored-by: Christopher Kolstad <chriswk@getunleash.ai>
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
Co-authored-by: Gastón Fournier <gaston@getunleash.ai>
Co-authored-by: Ivar Conradi Østhus <ivarconr@gmail.com>
Co-authored-by: sjaanus <sellinjaanus@gmail.com>
* fix: varidate-edge-tokens-schema tokens type
This change fixes the description of the 'tokens' array of the
validate edge tokens schema.
The source of the error was a simple inverson of anyOf and items.
* fix: update snapshot
* feat: use unleash flags for embedded proxy
* feat: add a separate flag for the proxy frontend
* fix: setup unleash in dev
* fix: check flagResolver on each request
* fix: remove unleash client setup
* refactor: update frontend routes snapshot
* refactor: make batchMetrics flag dynamic
* fix: always check dynamic CORS origins config
* fix: make conditionalMiddleware work with the OpenAPI schema generation
Co-authored-by: olav <mail@olav.io>
* refactor: remove unused API definition routes
* feat: embed proxy endpoints
* feat: check token metadata for alias if none is found
* fix: rename param
* feat: add test for retrieving token by alias
* fix: update schema
* fix: refactor to alias
* fix: refactor to null
* fix: update snapshot
* fix: update openapi snapshot
* fix: add check to getUserForToken
* refactor: add more token alias tests
* refactor: use timingSafeEqual for token comparisons
Co-authored-by: olav <mail@olav.io>
* refactor: remove unused API definition routes
* feat: add support for proxy keys
* feat: support listening for any event
* feat: embed proxy endpoints
* refactor: add an experimental flag for the embedded proxy
## PR text
I realized that the tag changes we introduced in #1907 would be breaking for people who use the unleash-server package and implement their own endpoints on top of it (as we do in unleash-enterprise).
This change makes it possible to still use the old tags. However, these tags are purposefully not added to the root schema or the list of OpenAPI tag types. Any of our endpoints still using them (I think there is one in Unleash enterprise, see ivarconr/unleash-enterprise#109) should switch over when possible.
## Commits
* fix: Add deprecated openapi tags as valid tags for operations
* Docs: add explanatory comment for why the type exists.
* Docs: start experimenting with OpenAPI and docusaurus
* Docs: add docusaurus-theme-openapi-docs pkg
* Wip: current status
* Docs: Add 'docusaurus-plugin-api-docs'
* Move openapi into own sidebar; generate from localhost
* Chore: Update docusaurus plugin for OpenAPI
* Add website/yarn.lock to git
* Fix: fix CSS warning by using flex-end instead of end
* docs: make openapi generated code work again
* docs: make tags work properly with openapi sidebar
* Docs/chore: update OpenAPI tag scheme.
Add a whole bunch of new tags to make it easier to understand
available tags in OpenAPI.
* docs: point to new openapi docs from old api docs
* docs: typo
* Docs: link restructure
* docs: add operation indicators to openapi docs
* docs: change badge color for operations
* docs: update openapi-docs package
It now sorts tags the same as the schema
* docs: pluralize APIs in slug
* docs: update links to generated api docs
* docs: update openapi snapshot tests with new tags
* docs: conditionally load spec from localhost or from file
* docs: Remove changes relating to immediate switchover
* refactor: rename types; extract into separate file
* docs: fix api doc links
* Feat: return reasons why a feature evaluated to true or false
Note: this is very rough and just straight ripped from the nodejs
client. It will need a lot of work, but is a good place to start
* Feat: add suggested shape for new payload
* Chore: minor cleanup
* Wip: make server compile again
* Remove unused schema ref
* Export new schemas
* Chore: fix some tests to use sub property
* Fix: fix some tests
* Refactor: rename some variables, uncomment some stuff
* Add segments type to bootstrap options
* Add segments capability to offline feature evaluator
* Fix function calls after turning params into an option abject
* Feat: test strategy order, etc
* Feat: add test to check that all strats are returned correctly
* Feat: allow you to include strategy ids in clients
* Wip: hook up segments in the offline client.
Note: compared to regular clients, they still fail
* Feat: add segments validation
* Fix: fix test case invariant.
* Chore: revert to returning only `boolean` from strategies.
This _should_ make it work with custom strategies too 🤞
* Feat: make more properties of the returned feature required
* Wip: add some comments and unfinished tests for edge cases
* Feat: add `isEnabledInCurrentEnvironment` prop
* Feat: consider more strategy failure cases
* Feat: test that isenabledinenvironment matches expectations
* Feat: add unknown strategies
* Fix: fix property access typo
* Feat: add unknown strategy for fallback purposes
* Feat: test edge case: all unknown strategies
* Feat: add custom strategy to arbitrary
* Feat: test that features can be true, even if not enabled in env
* Chore: add some comments
* Wip: fix sdk tests
* Remove comments, improve test logging
* Feat: add descriptions and examples to playground feature schema
* Switch `examples` for `example`
* Update schemas with descriptions and examples
* Fix: update snapshot
* Fix: openapi example
* Fix: merge issues
* Fix: fix issue where feature evaluation state was wrong
* Chore: update openapi spec
* Fix: fix broken offline client tests
* Refactor: move schemas into separate files
* Refactor: remove "reason" for incomplete evaluation.
The only instances where evaluation is incomplete is when we don't
know what the strategy is.
* Refactor: move unleash node client into test and dev dependencies
* Wip: further removal of stuff
* Chore: remove a bunch of code that we don't use
* Chore: remove comment
* Chore: remove unused code
* Fix: fix some prettier errors
* Type parameters in strategies to avoid `any`
* Fix: remove commented out code
* Feat: make `id` required on playground strategies
* Chore: remove redundant type
* Fix: remove redundant if and fix fallback evaluation
* Refactor: reduce nesting and remove duplication
* Fix: remove unused helper function
* Refactor: type `parameters` as `unknown`
* Chore: remove redundant comment
* Refactor: move constraint code into a separate file
* Refactor: rename `unleash` -> `feature-evaluator`
* Rename class `Unleash` -> `FeatureEvaluator`
* Refactor: remove this.ready and sync logic from feature evaluator
* Refactor: remove unused code, rename config type
* Refactor: remove event emission from the Unleash client
* Remove unlistened-for events in feature evaluator
* Refactor: make offline client synchronous; remove code
* Fix: update openapi snapshot after adding required strategy ids
* Feat: change `strategies` format.
This commit changes the format of a playground feature's `strategies`
properties from a list of strategies to an object with properties
`result` and `data`. It looks a bit like this:
```ts
type Strategies = {
result: boolean | "unknown",
data: Strategy[]
}
```
The reason is that this allows us to avoid the breaking change that
was previously suggested in the PR:
`feature.isEnabled` used to be a straight boolean. Then, when we found
out we couldn't necessarily evaluate all strategies (custom strats are
hard!) we changed it to `boolean | 'unevaluated'`. However, this is
confusing on a few levels as the playground results are no longer the
same as the SDK would be, nor are they strictly boolean anymore.
This change reverts the `isEnabled` functionality to what it was
before (so it's always a mirror of what the SDK would show).
The equivalent of `feature.isEnabled === 'unevaluated'` now becomes
`feature.isEnabled && strategy.result === 'unknown'`.
* Fix: Fold long string descriptions over multiple lines.
* Fix: update snapshot after adding line breaks to descriptions
* Wip: fix openapi spec
* Feat: add openapi enforcer for enforcing the generated schema
* Chore: Allow the example keyword in params
* Feat: add validator tests and fix some errors
* Use @apidevtools/swagger-parser for schema validation
* Wip: refactor tests for updated schema name
* Feat: update request params creation method
* Feat: add query params to state
* Refactor: move mapping test into separate function
* Refactor: rename request-parameters -> query-parameters
* Refactor: expose only finished query parameters
* Wip: fixup param types
* Refactor: remove unused types
* Chore: rename and cleanup
* Chore: cleanup
* Fix: Update snapshot
* Fix: use ?? Instead of paramToBool to get defaults
* Wip: generate query param object type from openapi params list
* Wip: use generated types for export query params
* Revert "Fix: use ?? Instead of paramToBool to get defaults"
This reverts commit 842567500b.
Because we accept bools, strings, and numbers, this is the only way to
do it.
* Chore: update and pin json-schema-to-ts
* Fix: use `&` to merge types
* Update snapshot
* Chore: rename export-parameters-schema -> export-query-parameters
When it ends in `schema`, the tests expect it to be included in the
openapi index file.
* strategy sort order endpoint
Co-authored-by: Fredrik Strand Oseberg <fredrik.no@gmail.com>
* feat: add e2e test for happy path
* add tests to features strategies order
Co-authored-by: Fredrik Strand Oseberg <fredrik.no@gmail.com>
* feat: add tests for sort-order
* fix: update snapshot
* fix: lint
Co-authored-by: Fredrik Strand Oseberg <fredrik.no@gmail.com>
* Implement user grouping feature for permissions
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
Co-authored-by: Jaanus Sellin <sellinjaanus@gmail.com>
Co-authored-by: Nuno Góis <github@nunogois.com>
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
* Chore: add unleash-client dependency
* Feat: add openapi specs for basic sdk contexts and playground reqs
* Feat: add openapi spec for response
* Feat: add openAPI entry for playground endpoint
* Fix: remove required 'projects' property that doesn't exist
* Refactor: add test placeholders for playground api
* Chore: improve openAPI description for playground request
* Refactor: align example project names
* Fix: update openapi snapshot
* Fix: summary -> description; example -> examples
* Feat: add fast-check and stub out one test.
The test doesn't work yet.
* Feat: add test and generator for sdk context schema
* Feat: add generators and tests for all new schemas
* Feat: test that the same input is returned exactly
* Feat: add more tests and more schemas
* Refactor: clean up tests some
* Refactor: simplify url friendliness check
* Refactor: fix types for playground request schema generator
* Feat: add bad request test
* Fix: make parameters the correct shape in generator
* Feat: scaffold out tests for service and endpoint
Liberal use of @ts-expect-error
* Fix: update snapshot with new model
* Add missing appName
* wip: stub out some extra tests
* Feat: model strategies for testing
* Feat: model variant payloads better
* Refactor: input params for function
* Refactor: use email address for user id generation
* Chore: update comment
* Wip: start stubbing out e2e tests
* Refactor: move tests requiring db to e2e file
* Fix: make e2e tests run as expected
* Fix: make toggle generator test work as expected
* Fix: increase timeout for long-running e2e test
* Wip: map toggles test
* Wip: test movement and cleanup
* Refactor: remove `AllowedStrings` in favor of typeof X[number]
* Wip: add e2e tests for the service
* Wip: tests in progress
* Feat: return fuller variant value
* Wip: delete redundant test.
Both those tests were testing versions of the same thing, so let's
delete one of them
* Feat: update openAPI snapshot
* Feat: hook up the playground service
* Feat: fix test cases for e2e api
* Refactor: get rid of _one_ 'as unknown as x' cast
* Fix: wait for the client to be ready before we pass it back
* Fix: weights go to 1000!
* Fix: fix some test assertions, add one more test to be sure
* Wip: add some test parameters to hopefully avoid timeouts
* Fix: don't init the client if there are no toggles
If you don't provide it with any toggles to bootstrap, then the client
will never be ready. This avoids that.
This adds two ways around it because we'll probably get away with a
bit less computation if we don't even try to initialize it. However,
we also don't want anyone else to make this mistake.
* Chore: modify test params
* Feat: use the type system to avoid empty lists for initialization
* Refactor: make tests simpler
* Feat: test basic context values
* Feat: test dynamic context values
* Fix: make custom context field test more reliable
* Feat: use unique arrays for toggles
* Feat: make `appName` required in context
* Fix: sdk context schema arbitrary: make appName at least 1 char long
* Fix: add a minimum length on appName in the context schema
* Fix: fix tests that fail due to new requirements
* Fix: update a test: remove variant mapping testing
* Fix: fix remaining tests
* Feat: rename response.toggles -> response.features
* Refactor: avoid single-letter predicate variables
* Refactor: extract offlineclient into its own file
* Refactor: move arbitraries into separate file
* Refactor: move playground requests into util function
* Fix: remove duplicate declaration of urlFriendlyString
* Chore: update comment
* Refactor: align on arbitrary generator naming
* Feat: Export single strategy arbitrary
* Refactor: move openapi utils into /util directory
* Refactor: move utils test into `util` directory
* Refactor: don't expose standard responses tied to status codes
* Feat: update empty response description + make it const
* Chore: update snapshot with new response descriptions
* refactor: add schemas to user admin controller
* refactor: remove unused SessionService
* refactor: fix search query type confusion
* refactor: add schemas to user controller (#1693)
* refactor: add schemas to user controller
* refactor: fix getAllUserSplashes method name
* refactor: name and email should not be required on create
* refactor: only some user fields may be updated
* refactor: should not require any fields on user update (#1730)
* refactor: send 400 instead of 500 on missing username and email
* refactor: should not require any fields for user update
* refactor: note that earlier versions required name or email
* refactor: merge roleDescriptionSchema and roleSchema
