Mirrors/unleash.unleash
1
0
Fork 0
mirror of https://github.com/Unleash/unleash.git synced 2025-03-18 00:19:49 +01:00
Code Issues Projects Releases Wiki Activity

Fix broken anchors in docs (#9406)

Browse Source
This commit is contained in:
Melinda Fekete 2025-03-11 11:45:40 +01:00 committed by GitHub
parent a064672635
commit 7534b66c18
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
43 changed files with 68 additions and 69 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@ -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)

2
frontend/src/component/admin/serviceAccounts/ServiceAccountsTable/ServiceAccountModal/ServiceAccountModal.tsx
View File

@ -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}
>

2
frontend/src/component/demo/demo-topics.tsx
View File

@ -315,7 +315,7 @@ export const TOPICS: ITutorialTopic[] = [
<>
<Description>
<a
href='https://docs.getunleash.io/reference/activation-strategies#gradual-rollout'
href='https://docs.getunleash.io/reference/activation-strategies'
target='_blank'
rel='noreferrer'
>

2
frontend/src/component/insights/componentsStat/HealthStats/HealthStats.tsx
View File

@ -99,7 +99,7 @@ export const HealthStats: FC<IHealthStatsProps> = ({
</StyledStatsRow>
<ExplanationRow>
<Link
href='https://docs.getunleash.io/reference/technical-debt'
href='https://docs.getunleash.io/reference/insights#health'
target='_blank'
rel='noreferrer'
>

4
frontend/src/component/user/Profile/PersonalAPITokensTab/CreatePersonalAPIToken/CreatePersonalAPIToken.tsx
View File

@ -119,8 +119,8 @@ export const CreatePersonalAPIToken: FC<ICreatePersonalAPITokenProps> = ({
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}
>
<StyledForm onSubmit={handleSubmit}>

2
src/lib/addons/new-relic-definition.ts
View File

@ -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: [
{

4
src/lib/openapi/spec/edge-token-schema.ts
View File

@ -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',

2
website/docs/feature-flag-tutorials/django/django-examples.md
View File

@ -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

2
website/docs/feature-flag-tutorials/dotnet/dotnet-examples.md
View File

@ -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

2
website/docs/feature-flag-tutorials/ios/examples.md
View File

@ -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

2
website/docs/feature-flag-tutorials/java/spring-boot-examples.md
View File

@ -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

2
website/docs/feature-flag-tutorials/python/examples.md
View File

@ -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

3
website/docs/feature-flag-tutorials/python/implementing-feature-flags.mdx
View File

@ -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.

2
website/docs/feature-flag-tutorials/rails/rails-examples.md
View File

@ -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

2
website/docs/feature-flag-tutorials/react/examples.md
View File

@ -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

2
website/docs/feature-flag-tutorials/ruby/ruby-examples.md
View File

@ -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

2
website/docs/feature-flag-tutorials/rust/rust-examples.md
View File

@ -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

2
website/docs/feature-flag-tutorials/use-cases/a-b-testing.md
View File

@ -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.

2
website/docs/feature-flag-tutorials/use-cases/gradual-rollout.md
View File

@ -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

6
website/docs/how-to/how-to-create-feature-toggles.md
View File

@ -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.
:::

2
website/docs/how-to/how-to-run-the-unleash-proxy.mdx
View File

@ -10,7 +10,7 @@ Placeholders in the code samples below are delimited by angle brackets (i.e. `<p
:::
The [Unleash Proxy](../reference/unleash-proxy) provides a way for you to consume feature flags in [front-end clients](../reference/sdks#front-end-sdks), such as the [JavaScript Proxy client](../reference/sdks/javascript-browser) and [React Proxy client](../reference/sdks/react).
The [Unleash Proxy](../reference/unleash-proxy) provides a way for you to consume feature flags in [front-end clients](../reference/sdks#client-side-sdks), such as the [JavaScript Proxy client](../reference/sdks/javascript-browser) and [React Proxy client](../reference/sdks/react).
Depending on your setup, the Proxy is most easily run in one of two ways, depending on your situation:

4
website/docs/quickstart.mdx
View File

@ -6,7 +6,7 @@ import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
This guide helps you set up Unleash in just a few minutes. The fastest way to get started is by using [Docker](#set-up-unleash-with-docker). If Docker doesn't work for you, see [other ways to try Unleash](#additional-ways-to-try-unleash).
This guide helps you set up Unleash in just a few minutes. The fastest way to get started is by using [Docker](#set-up-unleash-with-docker). If Docker doesn't work for you, see [other ways to try Unleash](#other-ways-to-try-unleash).
## Set up Unleash with Docker
@ -43,7 +43,7 @@ For more details on creating feature flags, see [How to create a feature flag](/
Next, use one of the client or server-side [SDKs](/reference/sdks) to connect Unleash with your application.
1. Create an API token:
- For client-side SDKs, use a [frontend token](/reference/api-tokens-and-client-keys#front-end-tokens).
- For client-side SDKs, use a [frontend token](/reference/api-tokens-and-client-keys#frontend-tokens).
- For server-side SDKs, use a [client token](/reference/api-tokens-and-client-keys#client-tokens).
2. Determine your Unleash URL:
- For client-side SDKs, use `<your-unleash-instance>/api/frontend`.

8
website/docs/reference/activation-strategies.md
View File

@ -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).

10
website/docs/reference/api-tokens-and-client-keys.mdx
View File

@ -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.
:::

2
website/docs/reference/api/legacy/unleash/admin/features-v2.mdx
View File

@ -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.
:::

2
website/docs/reference/api/legacy/unleash/admin/tags.md
View File

@ -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

2
website/docs/reference/change-requests.mdx
View File

@ -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.

2
website/docs/reference/environments.md
View File

@ -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

2
website/docs/reference/feature-toggle-variants.md
View File

@ -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

4
website/docs/reference/feature-toggles.mdx
View File

@ -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

2
website/docs/reference/front-end-api.md
View File

@ -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

1
website/docs/reference/integrations/integrations.mdx
View File

@ -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

2
website/docs/reference/playground.mdx
View File

@ -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.

4
website/docs/reference/projects.mdx
View File

@ -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:

6
website/docs/reference/resource-limits.mdx
View File

@ -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` |

9
website/docs/reference/sdks/index.mdx
View File

@ -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 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| <span id="strategy-constraints">**Category: [Strategy constraints](./activation-strategies#constraints)**</span> | | | | | | | | |
@ -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 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ |

4
website/docs/reference/segments.mdx
View File

@ -14,7 +14,7 @@ import VideoContent from '@site/src/components/VideoContent.jsx'
<VideoContent videoUrls={["https://www.youtube.com/embed/LWMCCFcRic0"]}/>
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

4
website/docs/reference/stickiness.md
View File

@ -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

4
website/docs/reference/unleash-context.md
View File

@ -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<string, string>` | 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.

4
website/docs/understanding-unleash/proxy-hosting.mdx
View File

@ -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:

2
website/docs/using-unleash/deploy/configuring-unleash.mdx
View File

@ -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

4
website/docs/using-unleash/troubleshooting/flag-abn-test-unexpected-result.md
View File

@ -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)

4
website/docs/using-unleash/troubleshooting/flag-not-returned.md
View File

@ -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.