## About the changes
When adding a new migration, we might run out of memory. Migrations have
only JS files and we're running these through TS parser. Removing TS
config reference from `.eslintrc` proved to solve the issue while
running local manual tests
This still lints migration files but using JS syntax
## About the changes
We need a way to have an audit log for operations made on Api Tokens.
These changes adds three new event types, API_TOKEN_CREATED,
API_TOKEN_UPDATED, API_TOKEN_DELETED and extends api-token-service to
store these to our event store to reflect the action being taken.
* This PR adds a configurable maxAge header to the CORS middleware. This
allows the preflight request to be cached so that we can reduce the
request load on our end for the frontend clients starting to utilise the
frontend api.
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
This PR introduces a soft landing page to the last viewed project or to
the project list (if there is more than 1 project)
Changes:
- Replaced clearing of `storage` with clearing `cache` in logout.ts ::
REVERTED
- Root redirects to `projects` instead of `features`
<!-- 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>
Previously we hard deleted the users, but due to change requests and
possibly other features in future, we really want to hard-link user
table and have meaningful relationships.
But this means, when user is deleted, all linked data is also deleted.
**Workaround is to soft delete users and just clear users data and keep
the relationships alive for audit logs.**
This PR implements this feature.
patches an issue where cloning a feature would clone variants for
it's last found environment in the db. This now will clone the feature
environments correctly
## 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.
## About the changes
This test fails randomly, example:
https://github.com/Unleash/unleash/actions/runs/3496006349/jobs/5853415518#step:5:376
It's not so frequent but I tested locally one out of 4 or 8 runs fails
because the rows returned are in the wrong order.
## Discussion points
If the order of segments is relevant, we should look into how we're
fetching them or applying a `sort()` before returning from the query.
I've validated on my machine that even if the segments are sent in
order, when pulled from the db sometimes they are processed in a
different order
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 implements the `all` endpoint of unleash-proxy, by adding an
experimental flag that can control the behaviour
## 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
Variants are now stored in each environment rather than in the feature
toggle. This enables RBAC, suggest changes, etc to also apply to
variants.
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#2254
### Important files
- **src/lib/db/feature-strategy-store.ts** a complex query was moved to
a view named `features_view`
- **src/lib/services/state-service.ts** export version number increased
due to the new format
## Discussion points
We're keeping the old column as a safeguard to be able to go back
Co-authored-by: sighphyre <liquidwicked64@gmail.com>
Co-authored-by: Christopher Kolstad <chriswk@getunleash.ai>
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 adds (back) the permissions and eventType module exports
## 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
https://linear.app/unleash/issue/2-425/variants-crud-new-environment-cards-with-tables-inside-add-edit-and
Basically created parallel components for the **variants per
environments** feature, so both flows should work correctly depending on
the feature flag state. Some of the duplication means that cleanup
should be straightforward - Once we're happy with this feature it should
be enough to delete
`frontend/src/component/feature/FeatureView/FeatureVariants/FeatureVariantsList`
and do some little extra cleanup.
I noticed we had some legacy-looking code in variants, so this involved
*some* rewriting of the current variants logic. Hopefully this new code
looks nicer, more maintainable, and more importantly **doesn't break
anything**.
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#2254
### Important files
Everything inside the
`frontend/src/component/feature/FeatureView/FeatureVariants/FeatureEnvironmentVariants`
folder.
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>
* fix: filter empty metrics before we collect last seen toggles.
fixes: #2104
* fix: add a last-seen service to batch last-seen toggle updates
Co-authored-by: Fredrik Strand Oseberg <fredrik.no@gmail.com>
* fix: PATs should have an unique description
* add pat validation on the back-end service
* Update src/lib/services/pat-service.ts
Co-authored-by: Simon Hornby <liquidwicked64@gmail.com>
* fix: only consider current user's PATs
* fix tests
* cleanup
* Update frontend/src/component/user/Profile/PersonalAPITokensTab/CreatePersonalAPIToken/CreatePersonalAPIToken.tsx
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
* Update src/test/e2e/api/admin/user/pat.e2e.test.ts
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
Co-authored-by: Simon Hornby <liquidwicked64@gmail.com>
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
* 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
* fix: slack back link url to point to the feature page
* update snapshots
* update feature link in case project info is available in event
* update missing snapshot
* feat: new user dropdown and profile page
* fix: add popup boxShadow to dark-theme
* fix: update routes snap
* refactor: move some tab specific logic into tabs component
* add useProfile hook example
* fix profile tab header (no name)
* fix: hide user popup when clicking profile link
* - add PATs to profile;
- add route logic to profile;
- refactor TimeAgoCell title;
- misc fixes and refactoring;
* add profile info to profile tab
* simplify req paths
* add PAT flag to the front-end
* fix: some UI adjustments
* change user popup buttons to links
* fix profile on front-end, add role description
* update delete PAT text
* address some PR comments
* address PR comments
* some more UI fixes and refactoring
* move password request to API hook
* 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>
* Middleware first version
* Middleware tests
* Add tests
* Finish middleware tests
* Add type for request
* Add flagresolver
* Fix snapshot
* Update flags and tests
* Put it back as default
* Update snapshot
* Add middleware test
* Middleware first version
* Middleware tests
* Add tests
* Finish middleware tests
* Add type for request
* Add flagresolver
* Fix snapshot
* Update flags and tests
* Put it back as default
* Update snapshot
* 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.
* Refactor(#1391): don't check for OpenAPI version in snapshot tests
remove the version from the received specification. The version
_is_ a required field, but having the version listed in automated
testing causes issues when trying to deploy new versions of the
API (due to mismatch between new tag versions etc). That's why we
remove it.
* #1391: test that the "semver" property is present
* #1391: test that the openapi version is valid semver
* Chore(#1391): comment formatting
* 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>
* fix: use the frontend dir from the backend
* Build is now working
* Fix workflows
* Fix workflows
* Fix build PRs
* Test coverage workflow
* Test coverage
* Test coverage run
* Fix jest report
* refactor: add missing frontend build
* refactor: ignore frontend dir for coverage
* refactor: run frontend build in PRs
* refactor: run backend tests in PRs
* Revert "refactor: run backend tests in PRs"
This reverts commit 22cabddfd1.
* refactor: remove unused frontend build file
* refactor: test workflows in PR
* refactor: use a prepare script for the frontend
* refactor: simplify yarn build scripts
* refactor: fix check-release script
* Revert "refactor: test workflows in PR"
This reverts commit 496ae19404.
* refactor: remove unused gitignore lines
* refactor: remove renovate config from the frontend repo
* refactor: remove frontend repo license
* refactor: remove frontend repo changelog
* refactor: update frontend repo readme
* refactor: add frontend node_modules to dockerignore
* refactor: update the docker yarn.lock snapshot
Co-authored-by: olav <mail@olav.io>
* fix: remove unused exp flag
* fix: remove unused flag
* fix: add support for external flag resolver
* fix: rename flagsresolver to flagresolver
* fix: disable external flag resolver
* fix: refactor a bit
* fix: stop using unleash in server-dev
* fix: remove userGroups flag
* fix: revert bumping frontend
* 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: batch feature metric inserts
* fix: use startOfHour when collapsing metrics
* refactor: avoid extra loop to sum yes/no values
* refactor: add experimental flag for batching metrics
