From 7534b66c182ff67c20a62616c91236177c521232 Mon Sep 17 00:00:00 2001 From: Melinda Fekete Date: Tue, 11 Mar 2025 11:45:40 +0100 Subject: [PATCH] Fix broken anchors in docs (#9406) --- README.md | 2 +- .../ServiceAccountModal/ServiceAccountModal.tsx | 2 +- frontend/src/component/demo/demo-topics.tsx | 2 +- .../componentsStat/HealthStats/HealthStats.tsx | 2 +- .../CreatePersonalAPIToken/CreatePersonalAPIToken.tsx | 4 ++-- src/lib/addons/new-relic-definition.ts | 2 +- src/lib/openapi/spec/edge-token-schema.ts | 4 ++-- .../feature-flag-tutorials/django/django-examples.md | 2 +- .../feature-flag-tutorials/dotnet/dotnet-examples.md | 2 +- website/docs/feature-flag-tutorials/ios/examples.md | 2 +- .../java/spring-boot-examples.md | 2 +- website/docs/feature-flag-tutorials/python/examples.md | 2 +- .../python/implementing-feature-flags.mdx | 3 +-- .../feature-flag-tutorials/rails/rails-examples.md | 2 +- website/docs/feature-flag-tutorials/react/examples.md | 2 +- .../docs/feature-flag-tutorials/ruby/ruby-examples.md | 2 +- .../docs/feature-flag-tutorials/rust/rust-examples.md | 2 +- .../feature-flag-tutorials/use-cases/a-b-testing.md | 2 +- .../use-cases/gradual-rollout.md | 2 +- website/docs/how-to/how-to-create-feature-toggles.md | 6 +++--- website/docs/how-to/how-to-run-the-unleash-proxy.mdx | 2 +- website/docs/quickstart.mdx | 4 ++-- website/docs/reference/activation-strategies.md | 8 ++++---- website/docs/reference/api-tokens-and-client-keys.mdx | 10 +++++----- .../reference/api/legacy/unleash/admin/features-v2.mdx | 2 +- .../docs/reference/api/legacy/unleash/admin/tags.md | 2 +- website/docs/reference/change-requests.mdx | 2 +- website/docs/reference/environments.md | 2 +- website/docs/reference/feature-toggle-variants.md | 2 +- website/docs/reference/feature-toggles.mdx | 4 ++-- website/docs/reference/front-end-api.md | 2 +- website/docs/reference/integrations/integrations.mdx | 1 + website/docs/reference/playground.mdx | 2 +- website/docs/reference/projects.mdx | 4 ++-- website/docs/reference/resource-limits.mdx | 6 +++--- website/docs/reference/sdks/index.mdx | 9 ++++----- website/docs/reference/segments.mdx | 4 ++-- website/docs/reference/stickiness.md | 4 ++-- website/docs/reference/unleash-context.md | 4 ++-- website/docs/understanding-unleash/proxy-hosting.mdx | 4 ++-- .../docs/using-unleash/deploy/configuring-unleash.mdx | 2 +- .../troubleshooting/flag-abn-test-unexpected-result.md | 4 ++-- .../using-unleash/troubleshooting/flag-not-returned.md | 4 ++-- 43 files changed, 68 insertions(+), 69 deletions(-) diff --git a/README.md b/README.md index 3299057f7f..8d0f5f2cac 100644 --- a/README.md +++ b/README.md @@ -137,7 +137,7 @@ Check out [the CONTRIBUTING.md file](./CONTRIBUTING.md) for contribution guideli - Get an overview of all feature flags across all your environments, applications and services - Targeted releases using [activation strategies](https://docs.getunleash.io/reference/activation-strategies) to enable and disable features for certain users or segments without having to redeploy your application. -- [Canary releases / gradual rollouts](https://docs.getunleash.io/reference/activation-strategies#gradual-rollout) +- [Canary releases / gradual rollouts](https://docs.getunleash.io/reference/activation-strategies) - [Kill switches](https://docs.getunleash.io/reference/feature-toggles#feature-flag-types) - [A/B testing](https://docs.getunleash.io/feature-flag-tutorials/use-cases/a-b-testing) - 2 [environments](https://docs.getunleash.io/reference/environments) diff --git a/frontend/src/component/admin/serviceAccounts/ServiceAccountsTable/ServiceAccountModal/ServiceAccountModal.tsx b/frontend/src/component/admin/serviceAccounts/ServiceAccountsTable/ServiceAccountModal/ServiceAccountModal.tsx index f37a2d4804..802ec156f5 100644 --- a/frontend/src/component/admin/serviceAccounts/ServiceAccountsTable/ServiceAccountModal/ServiceAccountModal.tsx +++ b/frontend/src/component/admin/serviceAccounts/ServiceAccountsTable/ServiceAccountModal/ServiceAccountModal.tsx @@ -271,7 +271,7 @@ export const ServiceAccountModal = ({ modal title={editing ? 'Edit service account' : 'New service account'} description='A service account is a special type of account that can only be used to authenticate with the Unleash API. Service accounts can be used to automate tasks.' - documentationLink='https://docs.getunleash.io' + documentationLink='https://docs.getunleash.io/reference/service-accounts' documentationLinkLabel='Service accounts documentation' formatApiCode={formatApiCode} > diff --git a/frontend/src/component/demo/demo-topics.tsx b/frontend/src/component/demo/demo-topics.tsx index 9ae30fce32..7dcb525269 100644 --- a/frontend/src/component/demo/demo-topics.tsx +++ b/frontend/src/component/demo/demo-topics.tsx @@ -315,7 +315,7 @@ export const TOPICS: ITutorialTopic[] = [ <> diff --git a/frontend/src/component/insights/componentsStat/HealthStats/HealthStats.tsx b/frontend/src/component/insights/componentsStat/HealthStats/HealthStats.tsx index 7f9396df9a..0519679cc4 100644 --- a/frontend/src/component/insights/componentsStat/HealthStats/HealthStats.tsx +++ b/frontend/src/component/insights/componentsStat/HealthStats/HealthStats.tsx @@ -99,7 +99,7 @@ export const HealthStats: FC = ({ diff --git a/frontend/src/component/user/Profile/PersonalAPITokensTab/CreatePersonalAPIToken/CreatePersonalAPIToken.tsx b/frontend/src/component/user/Profile/PersonalAPITokensTab/CreatePersonalAPIToken/CreatePersonalAPIToken.tsx index b26d911c3f..05a869698a 100644 --- a/frontend/src/component/user/Profile/PersonalAPITokensTab/CreatePersonalAPIToken/CreatePersonalAPIToken.tsx +++ b/frontend/src/component/user/Profile/PersonalAPITokensTab/CreatePersonalAPIToken/CreatePersonalAPIToken.tsx @@ -119,8 +119,8 @@ export const CreatePersonalAPIToken: FC = ({ description='Use personal API tokens to authenticate to the Unleash API as yourself. A personal API token has the same access privileges as your user.' - documentationLink='https://docs.getunleash.io/reference/api-tokens-and-client-keys' - documentationLinkLabel='Tokens documentation' + documentationLink='https://docs.getunleash.io/reference/api-tokens-and-client-keys#personal-access-tokens' + documentationLinkLabel='Personal access tokens documentation' formatApiCode={formatApiCode} > diff --git a/src/lib/addons/new-relic-definition.ts b/src/lib/addons/new-relic-definition.ts index e34079940b..088aa64ce6 100644 --- a/src/lib/addons/new-relic-definition.ts +++ b/src/lib/addons/new-relic-definition.ts @@ -21,7 +21,7 @@ const newRelicDefinition: IAddonDefinition = { name: 'new-relic', displayName: 'New Relic', description: 'Allows Unleash to post updates to New Relic Event API.', - documentationUrl: 'https://docs.getunleash.io/docs/addons/new-relic', + documentationUrl: 'https://docs.getunleash.io/reference/integrations', howTo: 'The New Relic integration allows Unleash to post Updates to New Relic Event API when a feature flag is updated.', parameters: [ { diff --git a/src/lib/openapi/spec/edge-token-schema.ts b/src/lib/openapi/spec/edge-token-schema.ts index 1944d6ecd9..7a85db0ce2 100644 --- a/src/lib/openapi/spec/edge-token-schema.ts +++ b/src/lib/openapi/spec/edge-token-schema.ts @@ -7,7 +7,7 @@ export const edgeTokenSchema = { additionalProperties: false, required: ['token', 'projects', 'type'], description: - 'A representation of a client token, limiting access to [CLIENT](https://docs.getunleash.io/reference/api-tokens-and-client-keys#client-tokens) (used by serverside SDKs) or [FRONTEND](https://docs.getunleash.io/reference/api-tokens-and-client-keys#front-end-tokens) (used by proxy SDKs)', + 'A representation of a client token, limiting access to [CLIENT](https://docs.getunleash.io/reference/api-tokens-and-client-keys#client-tokens) (used by serverside SDKs) or [FRONTEND](https://docs.getunleash.io/reference/api-tokens-and-client-keys#frontend-tokens) (used by proxy SDKs)', properties: { projects: { description: @@ -19,7 +19,7 @@ export const edgeTokenSchema = { example: ['developerexperience', 'enterprisegrowth'], }, type: { - description: `The [API token](https://docs.getunleash.io/reference/api-tokens-and-client-keys#api-tokens)'s **type**. Unleash supports three different types of API tokens ([ADMIN](https://docs.getunleash.io/reference/api-tokens-and-client-keys#admin-tokens), [CLIENT](https://docs.getunleash.io/reference/api-tokens-and-client-keys#client-tokens), [FRONTEND](https://docs.getunleash.io/reference/api-tokens-and-client-keys#front-end-tokens)). They all have varying access, so when validating a token it's important to know what kind you're dealing with`, + description: `The [API token](https://docs.getunleash.io/reference/api-tokens-and-client-keys)'s **type**. Unleash supports three different types of API tokens ([ADMIN](https://docs.getunleash.io/reference/api-tokens-and-client-keys#admin-tokens), [CLIENT](https://docs.getunleash.io/reference/api-tokens-and-client-keys#client-tokens), [FRONTEND](https://docs.getunleash.io/reference/api-tokens-and-client-keys#frontend-tokens)). They all have varying access, so when validating a token it's important to know what kind you're dealing with`, type: 'string', enum: Object.values(ApiTokenType), example: 'client', diff --git a/website/docs/feature-flag-tutorials/django/django-examples.md b/website/docs/feature-flag-tutorials/django/django-examples.md index 68654a687a..6cd9a50da8 100644 --- a/website/docs/feature-flag-tutorials/django/django-examples.md +++ b/website/docs/feature-flag-tutorials/django/django-examples.md @@ -94,7 +94,7 @@ Often, canary deployments are managed at the load balancer level while feature f Unleash has a few ways to help manage canary deployments for Django apps at scale: -- Using a [gradual rollout](/reference/activation-strategies#gradual-rollout) (which we [implemented in a previous section](#gradual-rollouts-for-python-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. +- Using a [gradual rollout](/reference/activation-strategies) (which we [implemented in a previous section](#gradual-rollouts-for-django-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. - Using either [constraints](/reference/activation-strategies#constraints) or [segments](/reference/segments) (which are a collection of constraints) for a subset of your users to get the new feature vs. the old feature, for _more_ control than a gradual rollout diff --git a/website/docs/feature-flag-tutorials/dotnet/dotnet-examples.md b/website/docs/feature-flag-tutorials/dotnet/dotnet-examples.md index 0989200bb2..0cafc5dc27 100644 --- a/website/docs/feature-flag-tutorials/dotnet/dotnet-examples.md +++ b/website/docs/feature-flag-tutorials/dotnet/dotnet-examples.md @@ -89,7 +89,7 @@ Often, canary deployments are managed at the load balancer level while feature f Unleash has a few ways to help manage canary deployments for .NET apps at scale: -- Using a [gradual rollout](/reference/activation-strategies#gradual-rollout) (which we [implemented in a previous section](#gradual-rollouts-for-net-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. +- Using a [gradual rollout](/reference/activation-strategies) (which we [implemented in a previous section](#gradual-rollouts-for-net-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. - Using either [constraints](/reference/activation-strategies#constraints) or [segments](/reference/segments) (which are a collection of constraints) for a subset of your users to get the new feature vs. the old feature, for _more_ control than a gradual rollout diff --git a/website/docs/feature-flag-tutorials/ios/examples.md b/website/docs/feature-flag-tutorials/ios/examples.md index 0c36e72fd1..88b86267e9 100644 --- a/website/docs/feature-flag-tutorials/ios/examples.md +++ b/website/docs/feature-flag-tutorials/ios/examples.md @@ -81,7 +81,7 @@ Often, canary deployments are managed at the load balancer level while feature f Unleash has a few ways to help manage canary deployments for iOS apps at scale: -- Using a [gradual rollout](/reference/activation-strategies#gradual-rollout) (which we [implemented in a previous section](#gradual-rollouts-for-ios-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. +- Using a [gradual rollout](/reference/activation-strategies) (which we [implemented in a previous section](#gradual-rollouts-for-ios-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. - Using either [constraints](/reference/activation-strategies#constraints) or [segments](/reference/segments) (which are a collection of constraints) for a subset of your users to get the new feature vs. the old feature, for _more_ control than a gradual rollout diff --git a/website/docs/feature-flag-tutorials/java/spring-boot-examples.md b/website/docs/feature-flag-tutorials/java/spring-boot-examples.md index 8a576211d8..7583e7c175 100644 --- a/website/docs/feature-flag-tutorials/java/spring-boot-examples.md +++ b/website/docs/feature-flag-tutorials/java/spring-boot-examples.md @@ -77,7 +77,7 @@ Often, canary deployments are managed at the load balancer level while feature f Unleash has a few ways to help manage canary deployments for Java apps at scale: -- Using a [gradual rollout](/reference/activation-strategies#gradual-rollout) (which we [implemented in a previous section](#gradual-rollouts-for-java-spring-boot-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. +- Using a [gradual rollout](/reference/activation-strategies) (which we [implemented in a previous section](#gradual-rollouts-for-java-spring-boot-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. - Using either [constraints](/reference/activation-strategies#constraints) or [segments](/reference/segments) (which are a collection of constraints) for a subset of your users to get the new feature vs. the old feature, for _more_ control than a gradual rollout diff --git a/website/docs/feature-flag-tutorials/python/examples.md b/website/docs/feature-flag-tutorials/python/examples.md index a141aee1de..4cf87e8ffc 100644 --- a/website/docs/feature-flag-tutorials/python/examples.md +++ b/website/docs/feature-flag-tutorials/python/examples.md @@ -93,7 +93,7 @@ Often, canary deployments are managed at the load balancer level while feature f Unleash has a few ways to help manage canary deployments for Python apps at scale: -- Using a [gradual rollout](/reference/activation-strategies#gradual-rollout) (which we [implemented in a previous section](#gradual-rollouts-for-python-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. +- Using a [gradual rollout](/reference/activation-strategies) (which we [implemented in a previous section](#gradual-rollouts-for-python-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. - Using either [constraints](/reference/activation-strategies#constraints) or [segments](/reference/segments) (which are a collection of constraints) for a subset of your users to get the new feature vs. the old feature, for _more_ control than a gradual rollout diff --git a/website/docs/feature-flag-tutorials/python/implementing-feature-flags.mdx b/website/docs/feature-flag-tutorials/python/implementing-feature-flags.mdx index 4341780c68..9a96c2b84f 100644 --- a/website/docs/feature-flag-tutorials/python/implementing-feature-flags.mdx +++ b/website/docs/feature-flag-tutorials/python/implementing-feature-flags.mdx @@ -23,9 +23,8 @@ Here are the steps we will cover in this tutorial: 2. [Spin up a local flag provider](#2-install-a-local-feature-flag-provider) 3. [Configure a feature flag](#3-create-and-configure-the-feature-flag) 4. [Add Unleash to a Python Flask app](#4-add-unleash-to-a-python-app) -5. [Toggle the database deletion route](#5-use-a-feature-flag-to-roll-out-a-delete-method) +5. [Toggle the database deletion route](#5-use-a-feature-flag-to-release-a-delete-method) 6. [Verify the feature flag experience](#6-verify-the-toggle-experience) -7. [Improve feature flag error handling](#7-improve-a-feature-flag-implementation-with-error-handling) Watch the video tutorial and follow along with the code from this documentation. diff --git a/website/docs/feature-flag-tutorials/rails/rails-examples.md b/website/docs/feature-flag-tutorials/rails/rails-examples.md index 87ff94d9fc..893c3e9dc0 100644 --- a/website/docs/feature-flag-tutorials/rails/rails-examples.md +++ b/website/docs/feature-flag-tutorials/rails/rails-examples.md @@ -93,7 +93,7 @@ Often, canary deployments are managed at the load balancer level while feature f Unleash has a few ways to help manage canary deployments for Ruby apps at scale: -- Using a [gradual rollout](/reference/activation-strategies#gradual-rollout) (which we [implemented in a previous section](#gradual-rollouts-for-ruby-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. +- Using a [gradual rollout](/reference/activation-strategies) (which we [implemented in a previous section](#gradual-rollouts-for-rails-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. - Using either [constraints](/reference/activation-strategies#constraints) or [segments](/reference/segments) (which are a collection of constraints) for a subset of your users to get the new feature vs. the old feature, for _more_ control than a gradual rollout diff --git a/website/docs/feature-flag-tutorials/react/examples.md b/website/docs/feature-flag-tutorials/react/examples.md index aa99258cfa..d80207abf3 100644 --- a/website/docs/feature-flag-tutorials/react/examples.md +++ b/website/docs/feature-flag-tutorials/react/examples.md @@ -96,7 +96,7 @@ Often, canary deployments are managed at the load balancer level while feature f Unleash has a few ways to help manage canary deployments for React apps at scale: -- Using a [gradual rollout](/reference/activation-strategies#gradual-rollout) (which we [implemented in a previous section](#gradual-rollouts-for-react-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. +- Using a [gradual rollout](/reference/activation-strategies) (which we [implemented in a previous section](#gradual-rollouts-for-react-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. - Using either [constraints](/reference/activation-strategies#constraints) or [segments](/reference/segments) (which are a collection of constraints) for a subset of your users to get the new feature vs. the old feature, for _more_ control than a gradual rollout diff --git a/website/docs/feature-flag-tutorials/ruby/ruby-examples.md b/website/docs/feature-flag-tutorials/ruby/ruby-examples.md index 36cea30f93..31f5aa0673 100644 --- a/website/docs/feature-flag-tutorials/ruby/ruby-examples.md +++ b/website/docs/feature-flag-tutorials/ruby/ruby-examples.md @@ -92,7 +92,7 @@ Often, canary deployments are managed at the load balancer level while feature f Unleash has a few ways to help manage canary deployments for Ruby apps at scale: -- Using a [gradual rollout](/reference/activation-strategies#gradual-rollout) (which we [implemented in a previous section](#gradual-rollouts-for-ruby-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. +- Using a [gradual rollout](/reference/activation-strategies) (which we [implemented in a previous section](#gradual-rollouts-for-ruby-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. - Using either [constraints](/reference/activation-strategies#constraints) or [segments](/reference/segments) (which are a collection of constraints) for a subset of your users to get the new feature vs. the old feature, for _more_ control than a gradual rollout diff --git a/website/docs/feature-flag-tutorials/rust/rust-examples.md b/website/docs/feature-flag-tutorials/rust/rust-examples.md index 9444057a78..7961f63ac8 100644 --- a/website/docs/feature-flag-tutorials/rust/rust-examples.md +++ b/website/docs/feature-flag-tutorials/rust/rust-examples.md @@ -113,7 +113,7 @@ Often, canary deployments are managed at the load balancer level while feature f Unleash has a few ways to help manage canary deployments for Rust apps: -- Using a [gradual rollout](/reference/activation-strategies#gradual-rollout) (which we [implemented in a previous section](#gradual-rollouts-for-rust-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. +- Using a [gradual rollout](/reference/activation-strategies) (which we [implemented in a previous section](#gradual-rollouts-for-rust-apps)) would be a simple use case but would reduce the amount of control you have over who gets the new feature. - Using either [constraints](/reference/activation-strategies#constraints) or [segments](/reference/segments) (which are a collection of constraints) for a subset of your users to get the new feature vs. the old feature, for _more_ control than a gradual rollout diff --git a/website/docs/feature-flag-tutorials/use-cases/a-b-testing.md b/website/docs/feature-flag-tutorials/use-cases/a-b-testing.md index 877ab50a8b..9839e4b8f5 100644 --- a/website/docs/feature-flag-tutorials/use-cases/a-b-testing.md +++ b/website/docs/feature-flag-tutorials/use-cases/a-b-testing.md @@ -17,7 +17,7 @@ In this tutorial, you will learn how to set up and run an A/B test using feature 2. [Target specific users for each test variant](#target-users-for-ab-testing) 3. [Manage cross-session visibility of test variants](#manage-user-session-behavior) 4. [Connect feature flag impression data to conversion outcomes](#track-ab-testing-for-your-key-performance-metrics) -5. [Roll out the winning variant to all users](#rollout-the-winning-variant-to-all-users) +5. [Roll out the winning variant to all users](#roll-out-the-winning-variant-to-all-users) You will also learn about how to [automate advanced A/B testing strategies](#multi-arm-bandit-tests-to-find-the-winning-variant) such as multi-arm bandit testing using feature flags. diff --git a/website/docs/feature-flag-tutorials/use-cases/gradual-rollout.md b/website/docs/feature-flag-tutorials/use-cases/gradual-rollout.md index 8b9efe6824..448799745f 100644 --- a/website/docs/feature-flag-tutorials/use-cases/gradual-rollout.md +++ b/website/docs/feature-flag-tutorials/use-cases/gradual-rollout.md @@ -162,7 +162,7 @@ Unleash provides the data to log any change that has happened over time, at the ![Events for a feature flag. The Event log tab is highlighted and the UI shows the most recent changes, including a JSON diff and the change details.](/img/unleash-toggle-history.png) -Learn more about [Event Log](/reference/events#event-log/) in our documentation. +Learn more about [Event Log](/reference/events#event-log) in our documentation. ### Managing Change Requests diff --git a/website/docs/how-to/how-to-create-feature-toggles.md b/website/docs/how-to/how-to-create-feature-toggles.md index f6b8b8d6dd..86215723b5 100644 --- a/website/docs/how-to/how-to-create-feature-toggles.md +++ b/website/docs/how-to/how-to-create-feature-toggles.md @@ -97,7 +97,7 @@ Constraints aren't fixed and can be changed later to further narrow your audienc :::tip API: Add constraints -You can either [add constraints when you add the strategy](/reference/api/legacy/unleash/admin/features-v2#add-strategy) or [PUT](/reference/api/legacy/unleash/admin/features-v2#update-strategy 'PUT an activation strategy') or [PATCH the strategy afterwards](/reference/api/legacy/unleash/admin/features-v2#put-strategy) +You can either [add constraints when you add the strategy](/reference/api/unleash/add-feature-strategy) or [PUT](/reference/api/unleash/update-feature-strategy) or [PATCH](/reference/api/unleash/patch-feature-strategy) the strategy later. ::: @@ -115,7 +115,7 @@ This can be done after you have created a strategy. :::tip API: add segments -Use the [API for adding segments to a strategy](/reference/api/legacy/unleash/admin/segments#replace-activation-strategy-segments) to add segments to your strategy. +Use the [API for adding segments to a strategy](/reference/api/unleash/update-feature-strategy-segments) to add segments to your strategy. ::: @@ -133,7 +133,7 @@ This can be done at any point after you've created your flag. :::tip API: add variants -Use the [update variants endpoint](/reference/api/legacy/unleash/admin/features-v2#update-variants). The payload should be your desired variant configuration. +Use the [create variants endpoint](/reference/api/unleash/overwrite-feature-variants) to create or overwrite existing variants in all environments. The payload should be your desired variant configuration. ::: diff --git a/website/docs/how-to/how-to-run-the-unleash-proxy.mdx b/website/docs/how-to/how-to-run-the-unleash-proxy.mdx index b110deca9a..8440070deb 100644 --- a/website/docs/how-to/how-to-run-the-unleash-proxy.mdx +++ b/website/docs/how-to/how-to-run-the-unleash-proxy.mdx @@ -10,7 +10,7 @@ Placeholders in the code samples below are delimited by angle brackets (i.e. `

/api/frontend`. diff --git a/website/docs/reference/activation-strategies.md b/website/docs/reference/activation-strategies.md index e7d866c885..9764b7f9cf 100644 --- a/website/docs/reference/activation-strategies.md +++ b/website/docs/reference/activation-strategies.md @@ -50,7 +50,7 @@ For example, if you have two constraints: one where the user email must have the A constraint has three parts: - A **context field**: The [context field](/reference/unleash-context) to use for evaluation. -- An **operator**: One of the [constraint operators](#strategy-constraint-operators). +- An **operator**: One of the [constraint operators](#constraint-operators). - **Values**: A value or list of values to use in the evaluation of the constraint. These parts turn the constraint into an expression that evaluates to true or false. Here are a few example constraints: @@ -63,7 +63,7 @@ These parts turn the constraint into an expression that evaluates to true or fal #### Constraint operators -Constraint operators help you define the conditional statements that get evaluated as part of the constraint. [Basic operators](#basic-operators) are available in all versions and SDKs. All other operators require Unleash version 4.9+ and [SDK compatibility](/reference/sdks#strategy-constraints). +Constraint operators help you define the conditional statements that get evaluated as part of the constraint. [Basic operators](#basic-operators) are available in all versions and SDKs. All other operators require Unleash version 4.9+ and [SDK compatibility](/reference/sdks#server-side-sdk-compatibility-table). All constraints can be negated. For example: @@ -130,7 +130,7 @@ The value must start with and contain at least major, minor, and patch versions. Server-side SDKs fetch the full feature flag configuration associated with your API key from Unleash. You can use API keys scoped to specific projects or environments to optimize payload size. -However, every value that you add to your feature flag constraints, increases the payload size. We recommend avoiding large constraint value lists. For example, instead of adding many user IDs or emails to the constraint value list, consider what properties those users share. This typically helps define and use a [custom context field](/reference/unleash-context#custom-context-field) instead. +However, every value that you add to your feature flag constraints, increases the payload size. We recommend avoiding large constraint value lists. For example, instead of adding many user IDs or emails to the constraint value list, consider what properties those users share. This typically helps define and use a [custom context field](/reference/unleash-context#custom-context-fields) instead. ## Add an activation strategy with a constraint @@ -149,7 +149,7 @@ To add an activation strategy with a constraint to a feature flag, do the follow Activation strategies are defined on the server but implemented client-side. The client determines whether a feature should be enabled based on the activation strategies. -All [server-side client SDKs](../reference/sdks#server-side-sdks) and [Unleash Edge](../reference/unleash-edge) implement the default activation strategy. The [front-end client SDKs](../reference/sdks#front-end-sdks) do not perform evaluations themselves. Instead, they rely on [Unleash Edge](../reference/unleash-edge) to handle the implementation and evaluation. +All [server-side client SDKs](../reference/sdks#server-side-sdks) and [Unleash Edge](../reference/unleash-edge) implement the default activation strategy. The [front-end client SDKs](../reference/sdks#client-side-sdks) do not perform evaluations themselves. Instead, they rely on [Unleash Edge](../reference/unleash-edge) to handle the implementation and evaluation. When using strategies with constraints, the client must provide the current [Unleash context](unleash-context) to the flag evaluation function for the evaluation to be done correctly. All official Unleash client SDKs support the option to pass dynamic context values to the `isEnabled()` function (or the SDK's equivalent). diff --git a/website/docs/reference/api-tokens-and-client-keys.mdx b/website/docs/reference/api-tokens-and-client-keys.mdx index 5d9967c30d..c32c41d5ba 100644 --- a/website/docs/reference/api-tokens-and-client-keys.mdx +++ b/website/docs/reference/api-tokens-and-client-keys.mdx @@ -9,7 +9,7 @@ Unleash uses API keys to facilitate communication between consuming clients such Unleash supports the following types of API tokens: - [Client tokens](#client-tokens) for connecting [server-side client SDKs](../reference/sdks#server-side-sdks), [Unleash Edge](../reference/unleash-edge), and [Unleash Proxy](../reference/unleash-proxy) to Unleash. -- [Frontend tokens](#frontend-tokens) for connecting [client-side SDKs](../reference/sdks#front-end-sdks) to Unleash using the [Frontend API](../reference/front-end-api) or [Unleash Edge](../reference/unleash-edge). +- [Frontend tokens](#frontend-tokens) for connecting [client-side SDKs](../reference/sdks#client-side-sdks) to Unleash using the [Frontend API](../reference/front-end-api) or [Unleash Edge](../reference/unleash-edge). - [Personal access tokens](#personal-access-tokens) for testing and debugging or providing temporary access to an automation tool. - [Service account tokens](/reference/service-accounts) for providing API access to integrations or automation tools. @@ -30,7 +30,7 @@ Client tokens cannot be used in frontend SDKs; use [frontend tokens](#frontend-t ### Frontend tokens -Use frontend tokens for connecting [frontend SDKs](../reference/sdks#front-end-sdks) to Unleash using the [Unleash Frontend API](./front-end-api) or [Unleash Edge](../reference/unleash-edge). They grant the user permission to: +Use frontend tokens for connecting [frontend SDKs](../reference/sdks#client-side-sdks) to Unleash using the [Unleash Frontend API](./front-end-api) or [Unleash Edge](../reference/unleash-edge). They grant the user permission to: - Reading enabled flags for a given context - Registering applications with the Unleash server - Sending usage metrics @@ -64,7 +64,7 @@ Admin tokens are deprecated. Use other token types: ::: -Admin tokens grant full read and write access to all resources in the Unleash server API. This includes all projects, all environments, and all [root resources](../reference/rbac#core-principles). +Admin tokens grant full read and write access to all resources in the Unleash server API. This includes all projects, all environments, and all [root resources](../reference/rbac). ## API token permissions @@ -161,13 +161,13 @@ Unleash Proxy is in maintenance mode. Use [Unleash Edge](../reference/unleash-ed ::: -You can use proxy client keys to connect [frontend SDKs](../reference/sdks#front-end-sdks) to [Unleash Proxy](../reference/unleash-proxy). Proxy client keys are not considered a secret and are safe to expose client-side. +You can use proxy client keys to connect [frontend SDKs](../reference/sdks#client-side-sdks) to [Unleash Proxy](../reference/unleash-proxy). Proxy client keys are not considered a secret and are safe to expose client-side. Proxy client keys are arbitrary strings that you provide the Unleash proxy with on startup. They can be any string you choose, and you create them yourself. :::info Creating proxy client keys -To designate a string as a proxy client key, add it to the `clientKeys` list when [starting the proxy](../reference/unleash-proxy#configuration). Connecting clients should then specify the same string as their client key. +To designate a string as a proxy client key, add it to the `clientKeys` list when [starting the proxy](../reference/unleash-proxy#configuration-options). Connecting clients should then specify the same string as their client key. ::: diff --git a/website/docs/reference/api/legacy/unleash/admin/features-v2.mdx b/website/docs/reference/api/legacy/unleash/admin/features-v2.mdx index 0b111e7edc..a0b9e5cd9d 100644 --- a/website/docs/reference/api/legacy/unleash/admin/features-v2.mdx +++ b/website/docs/reference/api/legacy/unleash/admin/features-v2.mdx @@ -615,7 +615,7 @@ Transfer-Encoding: chunked From 4.21 variants are tied to an environment. Check our Open API docs for the up-to-date docs: https://docs.getunleash.io/reference/api/unleash/features -This endpoint affects all environments at once. If you only want to update a single environment, use [#update-variants-per-environment](#update-variants-per-environment) instead. +This endpoint affects all environments at once. ::: diff --git a/website/docs/reference/api/legacy/unleash/admin/tags.md b/website/docs/reference/api/legacy/unleash/admin/tags.md index 03f61e14e7..cc43207348 100644 --- a/website/docs/reference/api/legacy/unleash/admin/tags.md +++ b/website/docs/reference/api/legacy/unleash/admin/tags.md @@ -155,7 +155,7 @@ Used to register a new tag type. This endpoint should be used to inform the serv **Notes:** -- if `name` is not unique, will return 409 CONFLICT, if you'd like to update an existing tag through admin-api look at [Update tag type](#Update-tag-type). +- if `name` is not unique, will return 409 CONFLICT, if you'd like to update an existing tag through admin-api look at [Update tag type](#update-tag-type). Returns 201-CREATED if the tag type was created successfully diff --git a/website/docs/reference/change-requests.mdx b/website/docs/reference/change-requests.mdx index e0ff79a58a..522abd6311 100644 --- a/website/docs/reference/change-requests.mdx +++ b/website/docs/reference/change-requests.mdx @@ -98,7 +98,7 @@ If a change request is scheduled and change requests are later disabled for the ::: -Changes to project [segments](/reference#segments), unlike global segments, also go through the change request process. +Changes to project [segments](/reference/segments), unlike global segments, also go through the change request process. While change requests are environment-specific, project segments are not. For this reason, Unleash allows you to attach segment changes to any environment where change requests are enabled. By default, Unleash selects the first available environment with change requests enabled, prioritizing [production](/reference/environments#environment-types) environments. diff --git a/website/docs/reference/environments.md b/website/docs/reference/environments.md index 0c0a5599fc..ca06deaa46 100644 --- a/website/docs/reference/environments.md +++ b/website/docs/reference/environments.md @@ -24,7 +24,7 @@ Each environment has a name and one of the following types: - Pre-production - Production -Meeting specific conditions in a given environment type affects a feature's [lifecycle stage](/reference/feature-toggles#feature-flag-lifecycle). For example, a feature that is receiving metrics and is exposed to users in a production environment moves to the [live](/reference/feature-toggles#live) stage. Production environments also display additional confirmation prompts for changes that may impact users. The default **production** environment is of type production. +Meeting specific conditions in a given environment type affects a feature's [lifecycle stage](/reference/feature-toggles#feature-flag-lifecycle). For example, a feature that is receiving metrics and is exposed to users in a production environment moves to the [live](/reference/feature-toggles#production) stage. Production environments also display additional confirmation prompts for changes that may impact users. The default **production** environment is of type production. ## Activation strategies diff --git a/website/docs/reference/feature-toggle-variants.md b/website/docs/reference/feature-toggle-variants.md index 2224c61eb2..a02bcc7c48 100644 --- a/website/docs/reference/feature-toggle-variants.md +++ b/website/docs/reference/feature-toggle-variants.md @@ -47,7 +47,7 @@ A variant has four components that define it: A variant's weight determines how likely it is that a user will receive that variant. It is a numeric value between 0 and 100 (inclusive) with one decimal's worth of precision. -When you have multiple variants, the sum of all their weights must add up to exactly 100. Depending on the [weight type](#weight-types), Unleash may automatically determine the weight of the new variant and balance it out with the other variants. +When you have multiple variants, the sum of all their weights must add up to exactly 100. Depending on the [weight type](#weight-types-and-calculation), Unleash may automatically determine the weight of the new variant and balance it out with the other variants. #### Weight types and calculation diff --git a/website/docs/reference/feature-toggles.mdx b/website/docs/reference/feature-toggles.mdx index 9268ee68bc..9ef51e3822 100644 --- a/website/docs/reference/feature-toggles.mdx +++ b/website/docs/reference/feature-toggles.mdx @@ -70,13 +70,13 @@ You can also manually change the state on a feature flag's page by going to **Ov Marking a flag as stale helps you deprecate a feature flag without removing the active configuration for connected applications. -You can use this to signal to your team to stop using the feature in your applications. Stale flags will show as stale in the [project status dashboard](./technical-debt#project-health). +You can use this to signal to your team to stop using the feature in your applications. Stale flags will show as stale in the [project status dashboard](./technical-debt#project-status). Marking a flag as stale generates the `feature-stale-on` [event](/reference/events#feature-stale-on). You can use [an integration](/reference/integrations) to trigger automated workflows, such as posting notifications in a Slack channel, breaking project builds if the code contains stale flags, or automatically opening pull requests to remove stale flags from the code. ### Configure expected lifetime -Each [feature flag type](#feature-flag-type) has a default expected lifetime. +Each [feature flag type](#feature-flag-types) has a default expected lifetime. With Admin access, you can configure these values. In the Admin UI, go to **Configure > Feature flag types** and edit the flag type you'd like to change. ## Feature flag lifecycle diff --git a/website/docs/reference/front-end-api.md b/website/docs/reference/front-end-api.md index b1c03982ea..ce3615f8c6 100644 --- a/website/docs/reference/front-end-api.md +++ b/website/docs/reference/front-end-api.md @@ -37,7 +37,7 @@ The client needs to point to the correct API endpoint. The Frontend API is avail ### API token -The client needs a frontend [token](../reference/api-tokens-and-client-keys.mdx#front-end-tokens) to interact with the Frontend API. +The client needs a frontend [token](../reference/api-tokens-and-client-keys.mdx#frontend-tokens) to interact with the Frontend API. ### Refresh interval for tokens diff --git a/website/docs/reference/integrations/integrations.mdx b/website/docs/reference/integrations/integrations.mdx index 346ae13951..ae38ede817 100644 --- a/website/docs/reference/integrations/integrations.mdx +++ b/website/docs/reference/integrations/integrations.mdx @@ -44,6 +44,7 @@ Our wonderful community has also created the following integrations: - [Fastify feature flags plugin](https://gitlab.com/m03geek/fastify-feature-flags#unleash-provider) - [Quarkus](https://github.com/quarkiverse/quarkus-unleash) - [Vue Unleash plugin](https://github.com/crishellco/vue-unleash) +- New Relic ## Integration events diff --git a/website/docs/reference/playground.mdx b/website/docs/reference/playground.mdx index 0953afdea2..1fac57d04d 100644 --- a/website/docs/reference/playground.mdx +++ b/website/docs/reference/playground.mdx @@ -119,6 +119,6 @@ The playground does not have any implementations for [custom strategies](../refe ### The Application Hostname strategy {#application-hostname} -The [application hostname strategy](../reference/activation-strategies#hostnames) is a little different from the other built-in strategies: it depends on external state and _not_ on the Unleash context to evaluate. In short, the strategy checks its application environment to get the hostname, so the Unleash context has no effect on the result of this strategy. +The [application hostname strategy](../reference/predefined-strategy-types#hosts) is a little different from the other built-in strategies: it depends on external state and _not_ on the Unleash context to evaluate. In short, the strategy checks its application environment to get the hostname, so the Unleash context has no effect on the result of this strategy. Because the application hostname strategy depends on external state, the playground can't guarantee whether the strategy would be true or false in a client. Further, the result in the playground would most likely be different from what you'd see in a client. Because of this, the playground does not evaluate this strategy. diff --git a/website/docs/reference/projects.mdx b/website/docs/reference/projects.mdx index b8fde132c9..7517468ffc 100644 --- a/website/docs/reference/projects.mdx +++ b/website/docs/reference/projects.mdx @@ -100,9 +100,9 @@ To move a feature flag between projects: ::: -Each project has a default strategy of [gradual rollout](./activation-strategies#gradual-rollout) to 100% of the user base. The default strategy only applies when **no active strategies** are defined for a flag in a specific environment. +Each project has a default strategy of [gradual rollout](./activation-strategies) to 100% of the user base. The default strategy only applies when **no active strategies** are defined for a flag in a specific environment. -You can change the default strategies of a project per environment. You can customize the default strategies by changing the rollout percentage and [stickiness](./stickiness) and adding [segments](./segments), [constraints](./activation-strategies#-constraints), and [variants](./strategy-variants). +You can change the default strategies of a project per environment. You can customize the default strategies by changing the rollout percentage and [stickiness](./stickiness) and adding [segments](./segments), [constraints](./activation-strategies#constraints), and [variants](./strategy-variants). To change the default strategy for an environment in a project: diff --git a/website/docs/reference/resource-limits.mdx b/website/docs/reference/resource-limits.mdx index 1f1d088ee8..289cb4f208 100644 --- a/website/docs/reference/resource-limits.mdx +++ b/website/docs/reference/resource-limits.mdx @@ -18,11 +18,11 @@ The resources and their respective limits and environment variables are: |--------------------------------------------------------------------------------------|--------------------------------------------------------|----------------------------------|-------------------------------------------------------|------------------------------------------------| | Active [feature flags](./feature-toggles) | 5,000 | 5,000 | 50,000 | `UNLEASH_FEATURE_FLAGS_LIMIT` | | [Strategies](./activation-strategies) per flag per environment | 30 | 30 | 30 | `UNLEASH_FEATURE_ENVIRONMENT_STRATEGIES_LIMIT` | -| [Constraints](./activation-strategies#-constraints) per strategy | 30 | 30 | 30 | `UNLEASH_CONSTRAINTS_LIMIT` | -| Values per [constraint](./activation-strategies#-constraints) | 250 | 250 | 1,000 | `UNLEASH_CONSTRAINT_VALUES_LIMIT` | +| [Constraints](./activation-strategies#constraints) per strategy | 30 | 30 | 30 | `UNLEASH_CONSTRAINTS_LIMIT` | +| Values per [constraint](./activation-strategies#constraints) | 250 | 250 | 1,000 | `UNLEASH_CONSTRAINT_VALUES_LIMIT` | | [Segments](./segments) | 300 | 300 | 300 | `UNLEASH_SEGMENTS_LIMIT` | | [Segments](./segments) per [strategy](./activation-strategies) | 5 | 5 | 5 | `UNLEASH_STRATEGY_SEGMENTS_LIMIT` | -| [Constraint](./activation-strategies#-constraints) values in a [segment](./segments) | 1,000 | 1,000 | 1,000 | `UNLEASH_SEGMENT_VALUES_LIMIT` | +| [Constraint](./activation-strategies#constraints) values in a [segment](./segments) | 1,000 | 1,000 | 1,000 | `UNLEASH_SEGMENT_VALUES_LIMIT` | | [API tokens](./api-tokens-and-client-keys) | 2,000 | 2,000 | 2,000 | `UNLEASH_API_TOKENS_LIMIT` | | [Projects](./projects) | 1 | 3 | 500 | `UNLEASH_PROJECTS_LIMIT` | | [Environments](./environments) | 2 | 2 | 50 | `UNLEASH_ENVIRONMENTS_LIMIT` | diff --git a/website/docs/reference/sdks/index.mdx b/website/docs/reference/sdks/index.mdx index d2322f865e..75b3e6b6a4 100644 --- a/website/docs/reference/sdks/index.mdx +++ b/website/docs/reference/sdks/index.mdx @@ -72,13 +72,12 @@ If you see an item marked with a ❌ that you would find useful, feel free to re | static | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | | function | ✅ | ✅ | ⭕ | ✅ | ✅ (4.3) | ✅ | ✅ | ⭕ | | **Category: Built-in strategies** | | | | | | | | | -| [Standard](./activation-strategies#standard) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | -| [Gradual rollout](./activation-strategies#gradual-rollout) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | -| [Gradual rollout: custom stickiness](./activation-strategies#customize-stickiness-beta) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | +| [Gradual rollout](./activation-strategies) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | +| [Gradual rollout: custom stickiness](./stickiness#custom-stickiness) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | | [UserID](./predefined-strategy-types#userids) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | [IP](./predefined-strategy-types#ips) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | [IP](./predefined-strategy-types#ips): CIDR syntax | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | ✅ | ✅ | -| [Hostname](./predefined-strategy-types#hostnames) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | +| [Hostname](./predefined-strategy-types#hosts) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | **Category: [Custom strategies](./custom-activation-strategies)** | | | | | | | | | | Basic support | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | **Category: [Strategy constraints](./activation-strategies#constraints)** | | | | | | | | | @@ -96,7 +95,7 @@ If you see an item marked with a ❌ that you would find useful, feel free to re | Basic support | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | Custom fallback variant | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | | Custom weight | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | -| [Custom stickiness](./stickiness#custom-stickiness-beta) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | +| [Custom stickiness](./stickiness#custom-stickiness) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | | [Strategy Variants](./strategy-variants)| ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | | **Category: Local backup** | | | | | | | | | | File-based backup | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | diff --git a/website/docs/reference/segments.mdx b/website/docs/reference/segments.mdx index 3c58e67809..edd915e825 100644 --- a/website/docs/reference/segments.mdx +++ b/website/docs/reference/segments.mdx @@ -14,7 +14,7 @@ import VideoContent from '@site/src/components/VideoContent.jsx' -A **segment** is a reusable collection of [strategy constraints](./activation-strategies#-constraints). Like with strategy constraints, you apply segments to [feature flag activation strategies](./activation-strategies). +A **segment** is a reusable collection of [strategy constraints](./activation-strategies#constraints). Like with strategy constraints, you apply segments to [feature flag activation strategies](./activation-strategies). You can apply the same segment to multiple activation strategies. If you update the segment, the changes will affect every strategy that uses that segment. @@ -30,7 +30,7 @@ Because segments stay in sync across strategies, any changes will propagate to a - release one or more new features at a specified time - create events with start and end times and guarantee that features will only be active during that period -Segments can be global or scoped to a specific project. If a segment is scoped to a single project, it can only be used in that project and it adheres to that project's [change request](./change-requests#change-request-for-segments "change requests for segments") settings. +Segments can be global or scoped to a specific project. If a segment is scoped to a single project, it can only be used in that project and it adheres to that project's [change request](./change-requests#change-requests-for-segments) settings. ## Structure and evaluation diff --git a/website/docs/reference/stickiness.md b/website/docs/reference/stickiness.md index 6179d31a46..8454c7d8ba 100644 --- a/website/docs/reference/stickiness.md +++ b/website/docs/reference/stickiness.md @@ -14,7 +14,7 @@ If both the user id and the session id is unavailable, the calculation returns a Because the number assigned to a user won't change, Unleash also guarantees that the a user will keep seeing the same features even if certain other parameters change. -For instance: When using the [gradual rollout activation strategy](../reference/activation-strategies#gradual-rollout), any user whose number is less than or equal to the rollout percentage will see the feature. This means that the same users will keep seeing the feature even as you increase the percentage of your user base that sees the feature. +For instance: When using the [gradual rollout activation strategy](../reference/activation-strategies), any user whose number is less than or equal to the rollout percentage will see the feature. This means that the same users will keep seeing the feature even as you increase the percentage of your user base that sees the feature. ## Custom stickiness @@ -24,7 +24,7 @@ For instance: When using the [gradual rollout activation strategy](../reference/ ::: -When using [the gradual rollout strategy](../reference/activation-strategies#gradual-rollout) or [feature flag variants](./feature-toggle-variants), you can use parameters other than the user id to calculate stickiness. More specifically, you can use any field, custom or otherwise, of the [Unleash Context](../reference/unleash-context) as long as you have enabled custom stickiness for these fields. +When using [the gradual rollout strategy](../reference/activation-strategies) or [feature flag variants](./feature-toggle-variants), you can use parameters other than the user id to calculate stickiness. More specifically, you can use any field, custom or otherwise, of the [Unleash Context](../reference/unleash-context) as long as you have enabled custom stickiness for these fields. ### Enabling custom stickiness diff --git a/website/docs/reference/unleash-context.md b/website/docs/reference/unleash-context.md index a49e2372d4..8165f22982 100644 --- a/website/docs/reference/unleash-context.md +++ b/website/docs/reference/unleash-context.md @@ -24,7 +24,7 @@ The following table gives an overview of the fields' intended usage, their lifet | `sessionId` | `string` | dynamic | The identifier of the current session. | | `remoteAddress` | `string` | dynamic | The application's IP address. | | `properties` | `Map` | dynamic | A key-value store for additional data. | -| `currentTime` | `DateTime`/`string` | dynamic | A `DateTime` (or similar) data class instance or a string in an RFC-3339 format. **Defaults to the current time** if not set by the user; requires [SDK compatibility](../reference/sdks#strategy-constraints-advanced-support). | +| `currentTime` | `DateTime`/`string` | dynamic | A `DateTime` (or similar) data class instance or a string in an RFC-3339 format. **Defaults to the current time** if not set by the user; requires [SDK compatibility](../reference/sdks#server-side-sdk-compatibility-table). | ### The `properties` field @@ -45,7 +45,7 @@ For operators that work on non-string types, such as numeric and datetime operat ::: -Custom context fields allow you to extend the Unleash Context with custom data. Each context field definition consists of a name and an optional description. Additionally, you can define a set of [_legal values_](#legal-values "legal values for custom context fields"), and define if the context field can be used in [custom stickiness calculations](../reference/stickiness#custom-stickiness) for the [gradual rollout strategy](activation-strategies#customize-stickiness-beta) and for [feature flag variants](../reference/feature-toggle-variants). +Custom context fields allow you to extend the Unleash Context with custom data. Each context field definition consists of a name and an optional description. Additionally, you can define a set of [_legal values_](#legal-values "legal values for custom context fields"), and define if the context field can be used in [custom stickiness calculations](../reference/stickiness#custom-stickiness) for the [gradual rollout strategy](../reference/activation-strategies) and for [feature flag variants](../reference/feature-toggle-variants). When interacting with custom context fields in code, they must be accessed via the Unleash Context's `properties` map, using the context field's name as the key. diff --git a/website/docs/understanding-unleash/proxy-hosting.mdx b/website/docs/understanding-unleash/proxy-hosting.mdx index ff4618f3a3..907943ae2d 100644 --- a/website/docs/understanding-unleash/proxy-hosting.mdx +++ b/website/docs/understanding-unleash/proxy-hosting.mdx @@ -53,7 +53,7 @@ Hosting Edge requires a little more setup than the Unleash-hosted Frontend API d Unleash no longer hosts instances of the proxy, but makes the [Frontend API](../reference/front-end-api) available to all [Pro](/availability#plans) and [Enterprise](https://www.getunleash.io/pricing) customers. The API is backed by an Amazon RDS database. Your applications can connect to the frontend API from your own cloud or from other hosting solutions. In order to access the frontend API you'll need: -- A [Frontend API key](../reference/api-tokens-and-client-keys#front-end-tokens) for the environment you'd like to use. +- A [Frontend API key](../reference/api-tokens-and-client-keys#frontend-tokens) for the environment you'd like to use. - The Frontend API URL. This will be your Unleash instance's URL followed by `/api/frontend`. This is the simplest, but also most limited (by far) way to use Unleash client SDKs. In this setup, Unleash hosts both the Unleash API and the Unleash frontend API. With Unleash hosting, you'll only need to worry about the Frontend API keys and the URL to access the endpoint. @@ -170,7 +170,7 @@ For the proxy, configure: - The Unleash API url. This is your Unleash instance URL followed by `/api`. - A [client API token](../reference/api-tokens-and-client-keys#client-tokens). -- One or more [proxy client keys](../reference/api-tokens-and-client-keys#proxy-client-keys). Refer to the [configuration section of the proxy document](../reference/unleash-proxy#configuration) for more details. +- One or more [proxy client keys](../reference/api-tokens-and-client-keys#proxy-client-keys). Refer to the [configuration section of the proxy document](../reference/unleash-proxy#configuration-options) for more details. For the proxy client SDK, configure: diff --git a/website/docs/using-unleash/deploy/configuring-unleash.mdx b/website/docs/using-unleash/deploy/configuring-unleash.mdx index 0ab6161a58..153c4f5d0d 100644 --- a/website/docs/using-unleash/deploy/configuring-unleash.mdx +++ b/website/docs/using-unleash/deploy/configuring-unleash.mdx @@ -51,7 +51,7 @@ For [more details, see here](./email-service.md) ## Further customization In order to customize "anything" in Unleash you need to -use [Unleash from Node.js](./getting-started.md#option-two---from-nodejs) or start +use [Unleash from Node.js](./getting-started#option-three---from-nodejs) or start the [docker image](./getting-started.md#option-one---use-docker) with environment variables. ```js diff --git a/website/docs/using-unleash/troubleshooting/flag-abn-test-unexpected-result.md b/website/docs/using-unleash/troubleshooting/flag-abn-test-unexpected-result.md index 7ce5b5f169..bf66182981 100644 --- a/website/docs/using-unleash/troubleshooting/flag-abn-test-unexpected-result.md +++ b/website/docs/using-unleash/troubleshooting/flag-abn-test-unexpected-result.md @@ -8,8 +8,8 @@ The first thing to look into is your feature configuration. If you're unsure whether the feature flag is being properly returned, you can go through the steps in this troubleshooting guide before proceeding: [My feature flag is not returned in the Frontend API/Edge/Proxy](/using-unleash/troubleshooting/flag-not-returned.md). -1. If you're using a [gradual rollout activation strategy](/reference/activation-strategies#gradual-rollout) be sure to set the rollout percentage to the percentage of your user base you would like to target for the test. If you would like to target 100% of your user base on your A/B/n test, confirm that your rollout percentage is set to 100%. Alternatively, you may want to consider using a [standard strategy](/reference/activation-strategies#standard) instead, since that means "active for everyone". This adjustment guarantees that all users participate in the A/B/n test, irrespective of the division ratio, be it an even 50-50 split, for a typical A/B test with 50% for Group A and 50% for Group B, or any other distribution that you configure in your variants. -2. When using a [gradual rollout strategy](/reference/activation-strategies#gradual-rollout), be mindful of the [stickiness](/reference/stickiness) value. If you're using default stickiness, confirm that either `userId` or `sessionId` are part of your context to ensure consistent results. Besides, if the provided context does not include the field used in the stickiness configuration, the gradual rollout strategy will be evaluated to `false` and therefore it will not be returned by the API. +1. Verify the rollout percentage of your gradual rollout [activation strategy](/reference/activation-strategies). If you would like to target 100% of your user base on your A/B/n test, confirm that your rollout percentage is set to 100%. +2. Check the [stickiness](/reference/stickiness) value. If you're using default stickiness, confirm that either `userId` or `sessionId` are part of your context to ensure consistent results. Besides, if the provided context does not include the field used in the stickiness configuration, the gradual rollout strategy will be evaluated to `false` and therefore it will not be returned by the API. 3. Ensure that your variants are correctly configured. You can refer to [feature flag variants](/reference/feature-toggle-variants). For example, if you would like to run a simple 50-50 A/B test, then your variants should look similar to this: ![An example of variants configured for an A/B test](/img/troubleshooting-flag-abn-test-unexpected-result-variants.png) diff --git a/website/docs/using-unleash/troubleshooting/flag-not-returned.md b/website/docs/using-unleash/troubleshooting/flag-not-returned.md index aa38826cb1..042a94a14b 100644 --- a/website/docs/using-unleash/troubleshooting/flag-not-returned.md +++ b/website/docs/using-unleash/troubleshooting/flag-not-returned.md @@ -9,8 +9,8 @@ The first thing to look into is to validate that the feature is well configured 1. Check that the feature is properly enabled: 1. Verify that the feature has a strategy associated to it that will return true for your context (ref: [add a strategy](/how-to-create-feature-flag#step-2)) 2. Verify that the feature has been enabled in the environment used by the client application (ref: [enabling a feature flag](/how-to-create-feature-flag#step-3)) -2. Check that your token is of the right [type](/reference/api-tokens-and-client-keys.mdx). To connect to the Frontend API, Edge or Proxy, you need to use a [Front-end token](/reference/api-tokens-and-client-keys#front-end-tokens) -3. Check that your token has access to the feature flag. The **token access configuration is immutable post-creation** and defines the set of features that the token can access. The different [parts of a token](/reference/api-tokens-and-client-keys#version-2) determine what projects and environment can be accessed: +2. Check that your token is of the right [type](/reference/api-tokens-and-client-keys.mdx). To connect to the Frontend API, Edge or Proxy, you need to use a [Front-end token](/reference/api-tokens-and-client-keys#frontend-tokens) +3. Check that your token has access to the feature flag. The **token access configuration is immutable post-creation** and defines the set of features that the token can access. The different [parts of a token](/reference/api-tokens-and-client-keys#api-token-format) determine what projects and environment can be accessed: 1. **Access to all projects (current and future)** - Tokens with a leading asterisk will provide access to all projects in a particular environment. For example, the token `*:production:xyz123etc...` will provide access to flags in the production environment of all projects. 2. **Access to a discrete list of projects** - Tokens with a leading set of square brackets (empty) will be given access to a subset of projects in a particular environment. The token will look similar to the following: `[]:production:xyz123etc...`. Which projects the token has access to can be found on the API Tokens page in the Unleash admin UI. 3. **Single project access** - Tokens that lead with a project name are bound to the specified project and environment. For example, `my_fullstack_app:production:xyz123etc...` will only have access to flags in the "my_fullstack_app" project as set in the production environment.