From e81f606d33900a90baf5e9918e8727a1fb326d43 Mon Sep 17 00:00:00 2001 From: Melinda Fekete Date: Thu, 17 Oct 2024 11:52:02 +0200 Subject: [PATCH] Fix incorrect md file extensions in docs (#8462) --- ...lags.md => implementing-feature-flags.mdx} | 0 ...pring-boot-implementing-feature-flags.mdx} | 0 ...lags.md => implementing-feature-flags.mdx} | 0 ...lags.md => implementing-feature-flags.mdx} | 0 ...-saml.md => how-to-add-sso-azure-saml.mdx} | 1 - .../how-to/how-to-add-strategy-constraints.md | 6 +-- .../how-to/how-to-capture-impression-data.mdx | 8 +-- ...reate-and-assign-custom-project-roles.mdx} | 0 .../how-to/how-to-create-feature-toggles.md | 28 +++++------ .../how-to-define-custom-context-fields.md | 4 +- .../how-to-environment-import-export.mdx | 22 ++++---- ...ort-export.md => how-to-import-export.mdx} | 0 .../how-to/how-to-run-the-unleash-proxy.mdx | 6 +-- .../how-to-schedule-feature-releases.mdx | 18 +++---- .../how-to-setup-provisioning-with-entra.md | 2 +- .../how-to/how-to-use-custom-strategies.md | 12 ++--- website/docs/quickstart.md | 10 ++-- website/docs/reference/actions.md | 8 +-- .../docs/reference/activation-strategies.md | 8 +-- .../reference/api-tokens-and-client-keys.mdx | 38 +++++++------- .../unleash/admin/{events.md => events.mdx} | 0 .../admin/{features-v2.md => features-v2.mdx} | 0 .../api/legacy/unleash/admin/features.md | 20 ++++---- .../api/legacy/unleash/admin/segments.mdx | 12 ++--- .../reference/api/legacy/unleash/index.md | 2 +- website/docs/reference/applications.mdx | 2 +- ...change-requests.md => change-requests.mdx} | 20 ++++---- website/docs/reference/environments.md | 2 +- .../docs/reference/feature-toggle-variants.md | 6 +-- website/docs/reference/feature-toggles.mdx | 6 +-- website/docs/reference/impression-data.md | 12 ++--- .../{integrations.md => integrations.mdx} | 24 ++++----- ....md => jira-cloud-plugin-installation.mdx} | 2 +- ...n-usage.md => jira-cloud-plugin-usage.mdx} | 4 +- .../{slack-app.md => slack-app.mdx} | 0 website/docs/reference/integrations/slack.md | 2 +- website/docs/reference/network-view.mdx | 4 +- website/docs/reference/playground.mdx | 14 +++--- .../reference/project-collaboration-mode.md | 8 +-- .../reference/{projects.md => projects.mdx} | 16 +++--- website/docs/reference/rbac.md | 6 +-- website/docs/reference/resource-limits.mdx | 32 ++++++------ .../reference/sdks/{index.md => index.mdx} | 30 +++++------ website/docs/reference/segments.mdx | 12 ++--- website/docs/reference/sso.md | 10 ++-- website/docs/reference/stickiness.md | 8 +-- ...onstraints.md => strategy-constraints.mdx} | 14 +++--- ...tegy-variants.md => strategy-variants.mdx} | 0 website/docs/reference/unleash-context.md | 18 +++---- website/docs/reference/whats-new-v4.md | 16 +++--- ...ure-flag.md => what-is-a-feature-flag.mdx} | 6 +-- ...ractices-using-feature-flags-at-scale.mdx} | 10 ++-- ...ces.md => feature-flag-best-practices.mdx} | 0 .../managing-constraints.mdx | 8 +-- .../the-anatomy-of-unleash.mdx | 50 +++++++++---------- .../understanding-unleash/unleash-overview.md | 10 ++-- .../{academy.md => academy.mdx} | 8 +-- ...nced-for-devs.md => advanced-for-devs.mdx} | 0 .../{foundational.md => foundational.mdx} | 0 ...ops.md => managing-unleash-for-devops.mdx} | 0 ...ing-unleash.md => configuring-unleash.mdx} | 0 .../using-unleash/deploy/email-service.md | 2 +- ...ading-unleash.md => upgrading-unleash.mdx} | 2 +- 63 files changed, 285 insertions(+), 284 deletions(-) rename website/docs/feature-flag-tutorials/java/{implementing-feature-flags.md => implementing-feature-flags.mdx} (100%) rename website/docs/feature-flag-tutorials/java/{spring-boot-implementing-feature-flags.md => spring-boot-implementing-feature-flags.mdx} (100%) rename website/docs/feature-flag-tutorials/python/{implementing-feature-flags.md => implementing-feature-flags.mdx} (100%) rename website/docs/feature-flag-tutorials/react/{implementing-feature-flags.md => implementing-feature-flags.mdx} (100%) rename website/docs/how-to/{how-to-add-sso-azure-saml.md => how-to-add-sso-azure-saml.mdx} (99%) rename website/docs/how-to/{how-to-create-and-assign-custom-project-roles.md => how-to-create-and-assign-custom-project-roles.mdx} (100%) rename website/docs/how-to/{how-to-import-export.md => how-to-import-export.mdx} (100%) rename website/docs/reference/api/legacy/unleash/admin/{events.md => events.mdx} (100%) rename website/docs/reference/api/legacy/unleash/admin/{features-v2.md => features-v2.mdx} (100%) rename website/docs/reference/{change-requests.md => change-requests.mdx} (87%) rename website/docs/reference/integrations/{integrations.md => integrations.mdx} (79%) rename website/docs/reference/integrations/{jira-cloud-plugin-installation.md => jira-cloud-plugin-installation.mdx} (97%) rename website/docs/reference/integrations/{jira-cloud-plugin-usage.md => jira-cloud-plugin-usage.mdx} (94%) rename website/docs/reference/integrations/{slack-app.md => slack-app.mdx} (100%) rename website/docs/reference/{projects.md => projects.mdx} (73%) rename website/docs/reference/sdks/{index.md => index.mdx} (87%) rename website/docs/reference/{strategy-constraints.md => strategy-constraints.mdx} (96%) rename website/docs/reference/{strategy-variants.md => strategy-variants.mdx} (100%) rename website/docs/topics/concepts/{what-is-a-feature-flag.md => what-is-a-feature-flag.mdx} (98%) rename website/docs/topics/feature-flags/{best-practices-using-feature-flags-at-scale.md => best-practices-using-feature-flags-at-scale.mdx} (95%) rename website/docs/topics/feature-flags/{feature-flag-best-practices.md => feature-flag-best-practices.mdx} (100%) rename website/docs/unleash-academy/{academy.md => academy.mdx} (87%) rename website/docs/unleash-academy/{advanced-for-devs.md => advanced-for-devs.mdx} (100%) rename website/docs/unleash-academy/{foundational.md => foundational.mdx} (100%) rename website/docs/unleash-academy/{managing-unleash-for-devops.md => managing-unleash-for-devops.mdx} (100%) rename website/docs/using-unleash/deploy/{configuring-unleash.md => configuring-unleash.mdx} (100%) rename website/docs/using-unleash/deploy/{upgrading-unleash.md => upgrading-unleash.mdx} (99%) diff --git a/website/docs/feature-flag-tutorials/java/implementing-feature-flags.md b/website/docs/feature-flag-tutorials/java/implementing-feature-flags.mdx similarity index 100% rename from website/docs/feature-flag-tutorials/java/implementing-feature-flags.md rename to website/docs/feature-flag-tutorials/java/implementing-feature-flags.mdx diff --git a/website/docs/feature-flag-tutorials/java/spring-boot-implementing-feature-flags.md b/website/docs/feature-flag-tutorials/java/spring-boot-implementing-feature-flags.mdx similarity index 100% rename from website/docs/feature-flag-tutorials/java/spring-boot-implementing-feature-flags.md rename to website/docs/feature-flag-tutorials/java/spring-boot-implementing-feature-flags.mdx diff --git a/website/docs/feature-flag-tutorials/python/implementing-feature-flags.md b/website/docs/feature-flag-tutorials/python/implementing-feature-flags.mdx similarity index 100% rename from website/docs/feature-flag-tutorials/python/implementing-feature-flags.md rename to website/docs/feature-flag-tutorials/python/implementing-feature-flags.mdx diff --git a/website/docs/feature-flag-tutorials/react/implementing-feature-flags.md b/website/docs/feature-flag-tutorials/react/implementing-feature-flags.mdx similarity index 100% rename from website/docs/feature-flag-tutorials/react/implementing-feature-flags.md rename to website/docs/feature-flag-tutorials/react/implementing-feature-flags.mdx diff --git a/website/docs/how-to/how-to-add-sso-azure-saml.md b/website/docs/how-to/how-to-add-sso-azure-saml.mdx similarity index 99% rename from website/docs/how-to/how-to-add-sso-azure-saml.md rename to website/docs/how-to/how-to-add-sso-azure-saml.mdx index e44a17b15c..05f042731c 100644 --- a/website/docs/how-to/how-to-add-sso-azure-saml.md +++ b/website/docs/how-to/how-to-add-sso-azure-saml.mdx @@ -1,6 +1,5 @@ --- title: How to add SSO with SAML 2.0 and Microsoft Entra ID -slug: 'how-to/how-to-add-sso-azure-saml' description: 'Configure Microsoft Entra ID SSO with SAML 2.0 for your Unleash instance.' --- diff --git a/website/docs/how-to/how-to-add-strategy-constraints.md b/website/docs/how-to/how-to-add-strategy-constraints.md index fe69f24d34..4c472c8fcd 100644 --- a/website/docs/how-to/how-to-add-strategy-constraints.md +++ b/website/docs/how-to/how-to-add-strategy-constraints.md @@ -8,7 +8,7 @@ title: How to add strategy constraints ::: -This guide shows you how to add [strategy constraints](../reference/strategy-constraints.md) to your feature flags using the Admin UI. For information on how to interact with strategy constraints from an [Unleash client SDK](../reference/sdks/index.md), visit the specific SDK's documentation or see [the relevant section in the strategy constraints documentation](../reference/strategy-constraints.md#sdks 'strategy constraints documentation, section on interacting with constraints from client SDKs'). +This guide shows you how to add [strategy constraints](../reference/strategy-constraints) to your feature flags using the Admin UI. For information on how to interact with strategy constraints from an [Unleash client SDK](../reference/sdks), visit the specific SDK's documentation or see [the relevant section in the strategy constraints documentation](../reference/strategy-constraints#sdks). ## Prerequisites @@ -26,9 +26,9 @@ On the "edit strategy" screen, select the "add constraint" button to open the co ## Step 2: Add and configure the constraint {#step-2} -Refer to [the _constraint structure_ section of the strategy constraints reference](../reference/strategy-constraints.md#constraint-structure) for a thorough explanation of the constraint fields. +Refer to [the _constraint structure_ section of the strategy constraints reference](../reference/strategy-constraints#constraint-structure) for a thorough explanation of the constraint fields. -1. From the "Context Field" dropdown, **select the context field** you would like to constrain the strategy on and **choose the [constraint operator](../reference/strategy-constraints.md#strategy-constraint-operators)** you want. +1. From the "Context Field" dropdown, **select the context field** you would like to constrain the strategy on and **choose the [constraint operator](../reference/strategy-constraints#strategy-constraint-operators)** you want. 2. **Define the values** to use for this constraint. The operator you selected decides whether you can define one or multiple values and what format they can have. 3. **Save the constraint** first. diff --git a/website/docs/how-to/how-to-capture-impression-data.mdx b/website/docs/how-to/how-to-capture-impression-data.mdx index 362602f8fd..0341844fc8 100644 --- a/website/docs/how-to/how-to-capture-impression-data.mdx +++ b/website/docs/how-to/how-to-capture-impression-data.mdx @@ -9,7 +9,7 @@ import VideoContent from "@site/src/components/VideoContent.jsx"; Placeholders in the code samples below are delimited by angle brackets (i.e. ``). You will need to replace them with the values that are correct in _your_ situation for the code samples to run properly. ::: -Unleash allows you to gather [**impression data**](../reference/impression-data.md) from your feature flags, giving you complete visibility into who checked what flags and when. What you do with this data is entirely up to you, but a common use case is to send it off to an aggregation and analytics service such as [Posthog](https://posthog.com/) or [Google Analytics](https://analytics.google.com/), either just for monitoring purposes or to facilitate [A/B testing](../feature-flag-tutorials/use-cases/a-b-testing.md). +Unleash allows you to gather [**impression data**](../reference/impression-data) from your feature flags, giving you complete visibility into who checked what flags and when. What you do with this data is entirely up to you, but a common use case is to send it off to an aggregation and analytics service such as [Posthog](https://posthog.com/) or [Google Analytics](https://analytics.google.com/), either just for monitoring purposes or to facilitate [A/B testing](../feature-flag-tutorials/use-cases/a-b-testing). This guide will take you through everything you need to do in Unleash to facilitate such a workflow. It will show you how to send data to Posthog as an example sink, but the exact same principles will apply to any other service of the same kind. @@ -22,7 +22,7 @@ We will assume that you have the necessary details for your third-party service: - **where to send the data to**. We'll refer to this in the code samples below as **``**. - **what format the data needs to be in**. This will determine how you transform the event data before you send it. -In addition, you'll need to have a flag to record impression data for and an [Unleash client SDK](../reference/sdks/index.md) that supports impression data. This guide will use the [JavaScript proxy SDK](/docs/generated/sdks/client-side/javascript-browser.md). +In addition, you'll need to have a flag to record impression data for and an [Unleash client SDK](../reference/sdks) that supports impression data. This guide will use the [JavaScript proxy SDK](/reference/sdks/javascript-browser). When you have those things sorted, follow the below steps. @@ -36,7 +36,7 @@ When you create a new feature flag via the UI, there's an option at the end of t ![The create feature flag form. There's a flag at the end of the form that enables or disables impression data. It's labeled "impression data".](/img/enable-impression-data.png) -To create a feature flag with impression data enabled, set the `impressionData` option to `true` in the request payload, as seen below. For more options, check the [reference docs on creating features](/reference/api/legacy/unleash/admin/features-v2.md#create-toggle). +To create a feature flag with impression data enabled, set the `impressionData` option to `true` in the request payload, as seen below. For more options, check the [reference docs on creating features](/reference/api/legacy/unleash/admin/features-v2#create-toggle). -The `"operator"` property in the code sample can be replaced with [any of the other date and time-based operators](../reference/strategy-constraints.md#date-and-time-operators) according to your needs. +The `"operator"` property in the code sample can be replaced with [any of the other date and time-based operators](../reference/strategy-constraints#date-and-time-operators) according to your needs. ## Schedule feature releases with custom activation strategies {#custom-activation-strategies} To schedule feature releases without using strategy constraints, you can use custom activation strategies. This requires defining a custom strategy and then implementing that strategy in your SDKs. For detailed instructions on how to do either of these things, refer to their respective how-to guides: -- [How to _define_ custom strategies](../how-to/how-to-use-custom-strategies.md#step-1) -- [How to _implement_ custom strategies](../how-to/how-to-use-custom-strategies.md#step-3) +- [How to _define_ custom strategies](../how-to/how-to-use-custom-strategies#step-1) +- [How to _implement_ custom strategies](../how-to/how-to-use-custom-strategies#step-3) ### Step 1: Define and apply a custom activation strategy -**Define a strategy** that takes a parameter that tells it when to activate (visit [the custom activation strategy reference documentation](../reference/custom-activation-strategies.md#definition) for full details on definitions): +**Define a strategy** that takes a parameter that tells it when to activate (visit [the custom activation strategy reference documentation](../reference/custom-activation-strategies#definition) for full details on definitions): 1. Give the strategy a name. We'll use `enableAfter`. 2. Give the strategy a required string parameter where the user can enter the time at which the feature should activate. Be sure to describe the format that the user must adhere to. 3. Save the strategy -[**Apply the strategy** to the feature flag](../how-to/how-to-use-custom-strategies.md#step-2) you want to schedule. +[**Apply the strategy** to the feature flag](../how-to/how-to-use-custom-strategies#step-2) you want to schedule. ![A custom activation strategy definition for a strategy called `enableAfter`. It takes a required parameter called `start time`: a string in a date format.](/img/custom-strategy-enable-after.png) ### Step 2: Implement the custom activation strategy in your clients -In each of the client SDKs that will interact with your feature, implement the strategy ([the implementation how-to guide](../how-to/how-to-use-custom-strategies.md#step-3) has steps for all SDK types). +In each of the client SDKs that will interact with your feature, implement the strategy ([the implementation how-to guide](../how-to/how-to-use-custom-strategies#step-3) has steps for all SDK types). diff --git a/website/docs/how-to/how-to-setup-provisioning-with-entra.md b/website/docs/how-to/how-to-setup-provisioning-with-entra.md index 4aae90d207..d937c8fef5 100644 --- a/website/docs/how-to/how-to-setup-provisioning-with-entra.md +++ b/website/docs/how-to/how-to-setup-provisioning-with-entra.md @@ -28,7 +28,7 @@ Enable SCIM by turning on the toggle and keep the token Unleash provides you for :::info Note -This guide assumes you already have an SSO application setup for Unleash. If you don't already have an application configured, please see our [guide](./how-to-add-sso-azure-saml.md) on setting up SSO. +This guide assumes you already have an SSO application setup for Unleash. If you don't already have an application configured, please see our [guide](./how-to-add-sso-azure-saml) on setting up SSO. ::: diff --git a/website/docs/how-to/how-to-use-custom-strategies.md b/website/docs/how-to/how-to-use-custom-strategies.md index 77a831dce6..b9fcd30a49 100644 --- a/website/docs/how-to/how-to-use-custom-strategies.md +++ b/website/docs/how-to/how-to-use-custom-strategies.md @@ -10,7 +10,7 @@ The downside of using a custom activation strategy instead of constraints is tha ::: -This guide takes you through how to use [custom activation strategies](../reference/custom-activation-strategies.md) with Unleash. We'll go through how you define a custom strategy in the admin UI, how you add it to a flag, and how you'd implement it in a [client SDK](../reference/sdks/index.md). +This guide takes you through how to use [custom activation strategies](../reference/custom-activation-strategies) with Unleash. We'll go through how you define a custom strategy in the admin UI, how you add it to a flag, and how you'd implement it in a [client SDK](../reference/sdks). In this example we want to define an activation strategy offers a scheduled release of a feature flag. This means that we want the feature flag to be activated after a given date and time. @@ -20,7 +20,7 @@ In this example we want to define an activation strategy offers a scheduled rele ![A visual guide for how to navigate to the strategies page in the Unleash admin UI. It shows the steps described in the preceding paragraph.](/img/custom-strategy-navigation.png) -2. **Define your strategy**. Use the "Add new strategy" button to open the strategy creation form. Fill in the form to define your strategy. Refer to [the custom strategy reference documentation](../reference/custom-activation-strategies.md#definition) for a full list of options. +2. **Define your strategy**. Use the "Add new strategy" button to open the strategy creation form. Fill in the form to define your strategy. Refer to [the custom strategy reference documentation](../reference/custom-activation-strategies#definition) for a full list of options. ![A strategy creation form. It has fields labeled "strategy name" — "TimeStamp" — and "description" — "activate flag after a given timestamp". It also has fields for a parameter named "enableAfter". The parameter is of type "string" and the parameter description is "Expected format: YYYY-MM-DD HH:MM". The parameter is required.](/img/timestamp_create_strategy.png) @@ -35,11 +35,11 @@ In this example we want to define an activation strategy offers a scheduled rele The steps to implement a custom strategy for your client depend on the kind of client SDK you're using: - if you're using a server-side client SDK, follow the steps in [option A](#step-3-a 'Step 3 option A: implement the strategy for a server-side client SDK'). -- if you're using a front-end client SDK ([Android](/docs/generated/sdks/client-side/android-proxy.md), [JavaScript](/docs/generated/sdks/client-side/javascript-browser.md), [React](/docs/generated/sdks/client-side/react.md), [iOS](/docs/generated/sdks/client-side/ios-proxy.md)), follow the steps in [option B](#step-3-b 'Step 3 option B: implementing the strategy for a front-end client SDK') +- if you're using a front-end client SDK ([Android](../reference/sdks/android-proxy), [JavaScript](../reference/sdks/javascript-browser)), [React](../reference/sdks/react), [iOS](../reference/sdks/ios-proxy)), follow the steps in [option B](#step-3-b 'Step 3 option B: implementing the strategy for a front-end client SDK') ### Option A: Implement the strategy for a server-side client SDK {#step-3-a} -1. **Implement the custom strategy** in your [client SDK](../reference/sdks/index.md). The exact way to do this will vary depending on the specific SDK you're using, so refer to the SDK's documentation. The example below shows an example of how you'd implement a custom strategy called "TimeStamp" for the [Node.js client SDK](/docs/generated/sdks/server-side/node.md). +1. **Implement the custom strategy** in your [client SDK](../reference/sdks). The exact way to do this will vary depending on the specific SDK you're using, so refer to the SDK's documentation. The example below shows an example of how you'd implement a custom strategy called "TimeStamp" for the [Node.js client SDK](../reference/sdks/node). ```js const { Strategy } = require('unleash-client'); @@ -89,14 +89,14 @@ The steps to implement a custom strategy for your client depend on the kind of c ### Option B: Implement the strategy for a front-end client SDK {#step-3-b} -Front-end client SDKs don't evaluate strategies directly, so you need to implement the **custom strategy in the [Unleash Proxy](../generated/unleash-proxy.md)**. Depending on how you run the Unleash Proxy, follow one of the below series of steps: +Front-end client SDKs don't evaluate strategies directly, so you need to implement the **custom strategy in the [Unleash Proxy](../reference/unleash-proxy)**. Depending on how you run the Unleash Proxy, follow one of the below series of steps: - If you're running the Unleash Proxy as a Docker container, refer to the [steps for using a containerized Proxy](#step-3-b-docker). - If you're using the Unleash Proxy via Node.js, refer to the [steps for using custom strategies via Node.js](#step-3-b-node). #### With a containerized proxy {#step-3-b-docker} -Strategies are stored in separate JavaScript files and loaded into the container at startup. Refer to [the Unleash Proxy documentation](../generated/unleash-proxy.md) for a full overview of all the options. +Strategies are stored in separate JavaScript files and loaded into the container at startup. Refer to [the Unleash Proxy documentation](../reference/unleash-proxy) for a full overview of all the options. 1. **Create a strategies directory.** Create a directory that Docker has access to where you can store your strategies. The next steps assume you called it `strategies` 2. **Initialize a Node.js project** and **install the Unleash Client**: diff --git a/website/docs/quickstart.md b/website/docs/quickstart.md index 206c15a59c..7f5735bf2a 100644 --- a/website/docs/quickstart.md +++ b/website/docs/quickstart.md @@ -29,15 +29,15 @@ password: unleash4all 2. Click 'New feature flag' 3. Give it a unique name, and click 'Create feature flag' -For a detailed guide on how to create a flag through the UI, [you can follow this guide](/how-to/how-to-create-feature-toggles.md). +For a detailed guide on how to create a flag through the UI, [you can follow this guide](/how-to/how-to-create-feature-toggles). ## 4a. Connect a client-side SDK {#connect-a-client-side-sdk} -To try Unleash with a client-side technology, create a [front-end token](/reference/api-tokens-and-client-keys.mdx#front-end-tokens) and use `/api/frontend` as the API URL. +To try Unleash with a client-side technology, create a [front-end token](/reference/api-tokens-and-client-keys#front-end-tokens) and use `/api/frontend` as the API URL. Now you can open your application code and connect through one of the [client-side SDKs](/reference/sdks#client-side-sdks). -The following example shows you how you could use the [JavaScript SDK](/generated/sdks/client-side/javascript-browser.md) to connect to the Unleash demo frontend API: +The following example shows you how you could use the [JavaScript SDK](/reference/sdks/javascript-browser) to connect to the Unleash demo frontend API: ```javascript import { UnleashClient } from "unleash-proxy-client"; @@ -62,7 +62,7 @@ unleash.on("synchronized", () => { To try Unleash with a server-side technology, create a [client token](/reference/api-tokens-and-client-keys#client-tokens) and use `/api` as the API URL. -Now you can open up your application code and create a connection to Unleash using one of our [SDKs](/reference/sdks/index.md). Here's an example using the [NodeJS SDK](/reference/sdks/node) to connect to the Unleash demo instance: +Now you can open up your application code and create a connection to Unleash using one of our [SDKs](/reference/sdks). Here's an example using the [NodeJS SDK](/reference/sdks/node) to connect to the Unleash demo instance: ```javascript const { initialize } = require("unleash-client"); @@ -116,4 +116,4 @@ You can run Unleash in the cloud by using our hosted offerings. Please see the [ ### Other Local Setup Options -There are several [more options to get started locally.](using-unleash/deploy/getting-started.md) +There are several [more options to get started locally.](using-unleash/deploy/getting-started) diff --git a/website/docs/reference/actions.md b/website/docs/reference/actions.md index eecc139624..7b517c0e11 100644 --- a/website/docs/reference/actions.md +++ b/website/docs/reference/actions.md @@ -34,11 +34,11 @@ When creating a new action you first need to specify a name and a description. T ### Source and filters -Then you need to select a source. If you haven't created a signal endpoint yet, you can do so by using the **Create new signal endpoint** link (more information on this in the [Signals](./signals.md) section). +Then you need to select a source. If you haven't created a signal endpoint yet, you can do so by using the **Create new signal endpoint** link (more information on this in the [Signals](./signals) section). If the source you selected already received at least one signal, you'll be able to see a preview of the latest signal received. This can help you define the different filters that need to match for the action to be executed. -Filters work similarly to [feature flag strategy constraints](./strategy-constraints.md), where the signal payload acts as the context for the constraint evaluation. +Filters work similarly to [feature flag strategy constraints](./strategy-constraints), where the signal payload acts as the context for the constraint evaluation. Filters are completely optional, so if you don't configure any filter your action will always be executed whenever you receive a new signal on the selected source. @@ -46,7 +46,7 @@ Filters are completely optional, so if you don't configure any filter your actio ### Actions -When these actions are triggered, they execute using the identity of a [service account](./service-accounts.md). As a result, when you later view events in [Event Log](./events#event-log), you’ll see this service account listed as the actor for those events. In order to execute the configured actions successfully, this service account needs to have the necessary permissions. This service account doesn't need an API token, so when creating it you can skip the token generation step and simply make sure it has the necessary permissions. +When these actions are triggered, they execute using the identity of a [service account](./service-accounts). As a result, when you later view events in [Event Log](./events#event-log), you’ll see this service account listed as the actor for those events. In order to execute the configured actions successfully, this service account needs to have the necessary permissions. This service account doesn't need an API token, so when creating it you can skip the token generation step and simply make sure it has the necessary permissions. The actions are executed in the same order that they are defined. If a previous action fails, the following actions will not be started. You can add multiple actions to an action set and you can add multiple action sets to a project. Depending on the action you want to execute you will have to provide different parameters. @@ -80,4 +80,4 @@ The limits are as follows: Ref: [Unleash Config](https://github.com/Unleash/unleash/blob/859fe098fedc261d646833012d9d408039491075/src/lib/create-config.ts#L577-L604) ## Sending signals to Unleash -See [Signals](./signals.md) +See [Signals](./signals) diff --git a/website/docs/reference/activation-strategies.md b/website/docs/reference/activation-strategies.md index 94367bdf2c..fa80bc5d92 100644 --- a/website/docs/reference/activation-strategies.md +++ b/website/docs/reference/activation-strategies.md @@ -4,11 +4,11 @@ title: Activation Strategies It is powerful to be able to turn a feature on and off instantaneously, without redeploying the application. Activation strategies let you enable a feature only for a specified audience. Different strategies use different parameters. Predefined strategies are bundled with Unleash. The recommended strategy is the gradual rollout strategy with 100% rollout, which basically means that the feature should be enabled to everyone. -Unleash comes with a number of built-in strategies (described below) that can be enhanced with [constraints](https://docs.getunleash.io/reference/strategy-constraints) for fine-grained control. For more advanced use cases, where constraints do not fulfill your needs, you can add your own [custom activation strategies](../reference/custom-activation-strategies.md). However, while activation strategies are _defined_ on the server, the server does not _implement_ the strategies. Instead, activation strategy implementation is done client-side. This means that it is _the client_ that decides whether a feature should be enabled or not. +Unleash comes with a number of built-in strategies (described below) that can be enhanced with [constraints](https://docs.getunleash.io/reference/strategy-constraints) for fine-grained control. For more advanced use cases, where constraints do not fulfill your needs, you can add your own [custom activation strategies](../reference/custom-activation-strategies). However, while activation strategies are _defined_ on the server, the server does not _implement_ the strategies. Instead, activation strategy implementation is done client-side. This means that it is _the client_ that decides whether a feature should be enabled or not. -All [server-side client SDKs](../reference/sdks/index.md#server-side-sdks) and the [Unleash Proxy](../generated/unleash-proxy.md) implement the default strategies (and allow you to add your own [custom strategy implementations](../reference/custom-activation-strategies.md#implementation)). The [front-end client SDKs](../reference/sdks/index.md#front-end-sdks) do not do the evaluation themselves, instead relying on the [Unleash Proxy](../generated/unleash-proxy.md) to take care of the implementation and evaluation. +All [server-side client SDKs](../reference/sdks#server-side-sdks) and the [Unleash Proxy](../reference/unleash-proxy) implement the default strategies (and allow you to add your own [custom strategy implementations](../reference/custom-activation-strategies#implementation)). The [front-end client SDKs](../reference/sdks#front-end-sdks) do not do the evaluation themselves, instead relying on the [Unleash Proxy](../reference/unleash-proxy) to take care of the implementation and evaluation. -Some activation strategies require the client to provide the current [Unleash context](unleash-context.md) to the flag evaluation function for the evaluation to be done correctly. +Some activation strategies require the client to provide the current [Unleash context](unleash-context) to the flag evaluation function for the evaluation to be done correctly. The following activation strategies are bundled with Unleash and always available: @@ -60,7 +60,7 @@ This strategy has the following modelling name in the code: :::note SDK compatibility -Custom stickiness is supported by all of our SDKs except for the Rust SDK. You can always refer to the [SDK compatibility table](../reference/sdks/index.md#server-side-sdk-compatibility-table) for the full overview. +Custom stickiness is supported by all of our SDKs except for the Rust SDK. You can always refer to the [SDK compatibility table](../reference/sdks#server-side-sdk-compatibility-table) for the full overview. ::: diff --git a/website/docs/reference/api-tokens-and-client-keys.mdx b/website/docs/reference/api-tokens-and-client-keys.mdx index e32413dcb3..14464e2dbe 100644 --- a/website/docs/reference/api-tokens-and-client-keys.mdx +++ b/website/docs/reference/api-tokens-and-client-keys.mdx @@ -2,7 +2,7 @@ title: API Tokens and Client Keys --- -For Unleash to be of any use, it requires at least a server and a [consuming client](../reference/sdks/index.md). More advanced use cases may call for multiple clients, automated feature flag updates, the [Unleash proxy](../generated/unleash-proxy.md) and [Unleash proxy clients](../reference/sdks/index.md#front-end-sdks), and more. To facilitate communication between all these moving parts, Unleash uses a system of API tokens and client keys, all with a specific purpose in mind. +For Unleash to be of any use, it requires at least a server and a [consuming client](../reference/sdks). More advanced use cases may call for multiple clients, automated feature flag updates, the [Unleash proxy](../reference/unleash-proxy) and [Unleash proxy clients](../reference/sdks#front-end-sdks), and more. To facilitate communication between all these moving parts, Unleash uses a system of API tokens and client keys, all with a specific purpose in mind. This document details the three kinds of tokens and keys that you will need to fully connect any Unleash system: @@ -14,7 +14,7 @@ This document details the three kinds of tokens and keys that you will need to f :::tip -This section describes what API tokens are. For information on how to create them, refer to the [how-to guide for creating API tokens](../how-to/how-to-create-api-tokens.mdx). +This section describes what API tokens are. For information on how to create them, refer to the [how-to guide for creating API tokens](../how-to/how-to-create-api-tokens). ::: @@ -54,10 +54,10 @@ By default, only admin users can create API tokens, and only admins can see thei However, any [client](#client-tokens client tokens) and [front-end tokens](#front-end-tokens) that are applicable to a project, will also be visible to any members of that project that have the `READ_PROJECT_API_TOKEN` permission (all project members by default). -Similarly, any project members with the `CREATE_PROJECT_API_TOKEN` permission can also create client and front-end tokens for that specific project ([how to create project API tokens](../how-to/how-to-create-project-api-tokens.mdx)). +Similarly, any project members with the `CREATE_PROJECT_API_TOKEN` permission can also create client and front-end tokens for that specific project ([how to create project API tokens](../how-to/how-to-create-project-api-tokens)). ### Admin tokens -**Admin tokens** grant _full read and write access_ to all resources in the Unleash server API. Admin tokens have access to all projects, all environments, and all root resources (find out more about [resources in the RBAC document](../reference/rbac.md#core-principles)). +**Admin tokens** grant _full read and write access_ to all resources in the Unleash server API. Admin tokens have access to all projects, all environments, and all root resources (find out more about [resources in the RBAC document](../reference/rbac#core-principles)). Use admin tokens to: @@ -65,7 +65,7 @@ Use admin tokens to: - Write custom Unleash UIs to replace the default Unleash admin UI. Do **not** use admin tokens for: -- [Client SDKs](../reference/sdks/index.md): You will _not_ be able to read flag data from multiple environments. Use [client tokens](#client-tokens) instead. +- [Client SDKs](../reference/sdks): You will _not_ be able to read flag data from multiple environments. Use [client tokens](#client-tokens) instead. Support for scoped admin tokens with more fine-grained permissions is currently in the planning stage. @@ -99,12 +99,12 @@ It is possible to set a token's expiration date to **never**. However, a token t Do **not** use personal access tokens for: -- [Client SDKs](../reference/sdks/index.md): You will _not_ be able to read flag data from multiple environments. Use [client tokens](#client-tokens) instead. +- [Client SDKs](../reference/sdks): You will _not_ be able to read flag data from multiple environments. Use [client tokens](#client-tokens) instead. - Write custom Unleash UIs: Personal access tokens may expire and their permissions may change. It's better to use [admin tokens](#admin-tokens) tokens instead. ### Client tokens -**Client tokens** are intended for use in [server-side client SDKs](../reference/sdks/index.md#server-side-sdks) (including the Unleash Proxy) and grant the user permissions to: +**Client tokens** are intended for use in [server-side client SDKs](../reference/sdks#server-side-sdks) (including the Unleash Proxy) and grant the user permissions to: - Read feature flag information - Register applications with the Unleash server @@ -116,18 +116,18 @@ Each client token is only **valid for a single environment**. Use client tokens: -- In [server-side client SDKs](../reference/sdks/index.md#server-side-sdks) -- To connect [the Unleash Proxy](../generated/unleash-proxy.md) to the Unleash API +- In [server-side client SDKs](../reference/sdks#server-side-sdks) +- To connect [the Unleash Proxy](../reference/unleash-proxy) to the Unleash API Do **not** use client tokens in: -- [Front-end SDKs](../reference/sdks/index.md#front-end-sdks). You will _not_ be able to connect to the Unleash server due to CORS restrictions. To connect front-end SDKs, choose one of the following options: -- Enable the [Unleash front-end API](./front-end-api.md) and create a [front-end token](#front-end-tokens). -- Configure an [Unleash Proxy](../generated/unleash-proxy.md) and use [Proxy client keys](#proxy-client-keys). +- [Front-end SDKs](../reference/sdks#front-end-sdks). You will _not_ be able to connect to the Unleash server due to CORS restrictions. To connect front-end SDKs, choose one of the following options: +- Enable the [Unleash front-end API](./front-end-api) and create a [front-end token](#front-end-tokens). +- Configure an [Unleash Proxy](../reference/unleash-proxy) and use [Proxy client keys](#proxy-client-keys). ### Front-end tokens -**Front-end tokens** are used with [front-end SDKs](../reference/sdks/index.md#front-end-sdks) when used with the [Unleash front-end API](./front-end-api.md). They grant the user permission to: +**Front-end tokens** are used with [front-end SDKs](../reference/sdks#front-end-sdks) when used with the [Unleash front-end API](./front-end-api). They grant the user permission to: - Read the enabled flags for a given context - Register applications with the Unleash server @@ -139,15 +139,15 @@ Each front-end token is only **valid for a single environment**. Use front-end tokens in: -- [Front-end SDKs (also known as _proxy clients_)](../reference/sdks/index.md#front-end-sdks). +- [Front-end SDKs (also known as _proxy clients_)](../reference/sdks#front-end-sdks). Do **not** use front-end tokens in: -- [Server-side SDKs](../reference/sdks/index.md#server-side-sdks). The format is different, so they won't work correctly. +- [Server-side SDKs](../reference/sdks#server-side-sdks). The format is different, so they won't work correctly. ### Format -API tokens come in one of two formats. When we introduced [environments](./environments.md) in Unleash 4.3, we updated the format of the tokens to provide more human-readable information to the user. Both formats are still valid (you don't need to update a working token of the old format) and are described below. +API tokens come in one of two formats. When we introduced [environments](./environments) in Unleash 4.3, we updated the format of the tokens to provide more human-readable information to the user. Both formats are still valid (you don't need to update a working token of the old format) and are described below. #### Version 1 @@ -200,13 +200,13 @@ Some example client tokens are: ## Proxy client keys {#proxy-client-keys} -Use proxy client keys to connect [Proxy client SDKs (front-end SDKs)](../reference/sdks/index.md#front-end-sdks) to the [Unleash Proxy](../generated/unleash-proxy.md). As opposed to the [API tokens](#api-tokens), Proxy client keys are _not_ considered secret and are safe to use on any clients (refer to the [the proxy documentation for more about privacy](../generated/unleash-proxy.md#we-care-about-privacy)). They do _not_ let you connect to the Unleash server API. +Use proxy client keys to connect [Proxy client SDKs (front-end SDKs)](../reference/sdks#front-end-sdks) to the [Unleash Proxy](../reference/unleash-proxy). As opposed to the [API tokens](#api-tokens), Proxy client keys are _not_ considered secret and are safe to use on any clients (refer to the [the proxy documentation for more about privacy](../reference/unleash-proxy#we-care-about-privacy)). They do _not_ let you connect to the Unleash server API. Proxy client keys are arbitrary strings that you _must_ provide the Unleash proxy with on startup. They can be whatever you want 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, as mentioned in the [_configuration_ section of the Unleash proxy documentation](../generated/unleash-proxy.md#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, as mentioned in the [_configuration_ section of the Unleash proxy documentation](../reference/unleash-proxy#configuration). Connecting clients should then specify the same string as their client key. ::: @@ -214,7 +214,7 @@ Unleash does not generate proxy client keys for you. Because of this, they have Use Proxy client keys to: -- Connect [Proxy client SDKs](../reference/sdks/index.md#front-end-sdks) to the [Unleash Proxy](../generated/unleash-proxy.md) +- Connect [Proxy client SDKs](../reference/sdks#front-end-sdks) to the [Unleash Proxy](../reference/unleash-proxy) - Connect your own custom Proxy clients (or pure HTTP requests) to the Unleash Proxy Do **not** use Proxy client keys to: diff --git a/website/docs/reference/api/legacy/unleash/admin/events.md b/website/docs/reference/api/legacy/unleash/admin/events.mdx similarity index 100% rename from website/docs/reference/api/legacy/unleash/admin/events.md rename to website/docs/reference/api/legacy/unleash/admin/events.mdx diff --git a/website/docs/reference/api/legacy/unleash/admin/features-v2.md b/website/docs/reference/api/legacy/unleash/admin/features-v2.mdx similarity index 100% rename from website/docs/reference/api/legacy/unleash/admin/features-v2.md rename to website/docs/reference/api/legacy/unleash/admin/features-v2.mdx diff --git a/website/docs/reference/api/legacy/unleash/admin/features.md b/website/docs/reference/api/legacy/unleash/admin/features.md index d903f6f298..131ddf3661 100644 --- a/website/docs/reference/api/legacy/unleash/admin/features.md +++ b/website/docs/reference/api/legacy/unleash/admin/features.md @@ -4,7 +4,7 @@ title: /api/admin/features :::caution Deprecation notice -Most of this API was removed in Unleash v5 (after being deprecated since Unleash v4.3). You should use [the project-based API (/api/admin/projects/:projectId)](/reference/api/legacy/unleash/admin/features-v2.md) instead. +Most of this API was removed in Unleash v5 (after being deprecated since Unleash v4.3). You should use [the project-based API (/api/admin/projects/:projectId)](/reference/api/legacy/unleash/admin/features-v2.mdx) instead. ::: @@ -18,7 +18,7 @@ In order to access the admin API endpoints you need to identify yourself. Unless :::caution Deprecation notice -This endpoint was removed in Unleash v5. Please use the [project-based endpoint to fetch all flags](/reference/api/legacy/unleash/admin/features-v2.md#fetching-toggles) instead. +This endpoint was removed in Unleash v5. Please use the [project-based endpoint to fetch all flags](/reference/api/legacy/unleash/admin/features-v2.mdx#fetching-toggles) instead. ::: @@ -112,7 +112,7 @@ Response format is the same as `api/admin/features` :::caution Removal notice -This endpoint was removed in Unleash v5 (deprecated since v4). Please use the [project-based endpoint to fetch specific flags](/reference/api/legacy/unleash/admin/features-v2.md#get-toggle) instead. +This endpoint was removed in Unleash v5 (deprecated since v4). Please use the [project-based endpoint to fetch specific flags](/reference/api/legacy/unleash/admin/features-v2.mdx#get-toggle) instead. ::: @@ -142,7 +142,7 @@ Used to fetch details about a specific featureToggle. This is mostly provded to :::caution Removal notice -This endpoint was removed in Unleash v5 (deprecated since v4). Please use the [project-based endpoint to create feature flags](/reference/api/legacy/unleash/admin/features-v2.md#create-toggle) instead. +This endpoint was removed in Unleash v5 (deprecated since v4). Please use the [project-based endpoint to create feature flags](/reference/api/legacy/unleash/admin/features-v2.mdx#create-toggle) instead. ::: @@ -180,7 +180,7 @@ Returns 200-response if the feature flag was created successfully. ## Update a Feature Flag {#update-a-feature-toggle} :::caution Removal notice -This endpoint was removed in Unleash v5. Please use the [project-based endpoint to update a feature flag](/reference/api/legacy/unleash/admin/features-v2.md#update-toggle) instead. +This endpoint was removed in Unleash v5. Please use the [project-based endpoint to update a feature flag](/reference/api/legacy/unleash/admin/features-v2.mdx#update-toggle) instead. ::: @@ -253,7 +253,7 @@ Removes the specified tag from the `(type, value)` tuple from the Feature Flag's ## Archive a Feature Flag {#archive-a-feature-toggle} :::caution Removal notice -This endpoint was removed in v5. Please use the [project-based endpoint to archive flags](/reference/api/legacy/unleash/admin/features-v2.md#archive-toggle) instead. +This endpoint was removed in v5. Please use the [project-based endpoint to archive flags](/reference/api/legacy/unleash/admin/features-v2.mdx#archive-toggle) instead. ::: @@ -264,7 +264,7 @@ Used to archive a feature flag. A feature flag can never be totally be deleted, ## Enable a Feature Flag {#enable-a-feature-toggle} :::caution Removal notice -This endpoint was removed in v5. Please use the [project-based endpoint to enable feature flags](/reference/api/legacy/unleash/admin/features-v2.md#enable-env) instead. +This endpoint was removed in v5. Please use the [project-based endpoint to enable feature flags](/reference/api/legacy/unleash/admin/features-v2.mdx#enable-env) instead. ::: @@ -298,7 +298,7 @@ None ## Disable a Feature Flag {#disable-a-feature-toggle} :::caution Removal notice -This endpoint was removed in v5. Please use the [project-based endpoint to disable feature flags](/reference/api/legacy/unleash/admin/features-v2.md#disable-env) instead. +This endpoint was removed in v5. Please use the [project-based endpoint to disable feature flags](/reference/api/legacy/unleash/admin/features-v2.mdx#disable-env) instead. ::: `POST: http://unleash.host.com/api/admin/features/:featureName/toggle/off` @@ -332,7 +332,7 @@ None ## Mark a Feature Flag as "stale" {#mark-a-feature-toggle-as-stale} :::caution Removal notice -This endpoint was removed in v5. Please use the [project-based endpoint to patch a feature flag and mark it as stale](/reference/api/legacy/unleash/admin/features-v2.md#patch-toggle) instead. +This endpoint was removed in v5. Please use the [project-based endpoint to patch a feature flag and mark it as stale](/reference/api/legacy/unleash/admin/features-v2.mdx#patch-toggle) instead. ::: @@ -367,7 +367,7 @@ None ## Mark a Feature Flag as "active" {#mark-a-feature-toggle-as-active} :::caution Removal notice -This endpoint was removed in v5. Please use the [project-based endpoint to patch a feature flag and mark it as not stale](/reference/api/legacy/unleash/admin/features-v2.md#patch-toggle) instead. +This endpoint was removed in v5. Please use the [project-based endpoint to patch a feature flag and mark it as not stale](/reference/api/legacy/unleash/admin/features-v2.mdx#patch-toggle) instead. ::: `POST: http://unleash.host.com/api/admin/features/:featureName/stale/off` diff --git a/website/docs/reference/api/legacy/unleash/admin/segments.mdx b/website/docs/reference/api/legacy/unleash/admin/segments.mdx index fb3e351865..ab99ce927d 100644 --- a/website/docs/reference/api/legacy/unleash/admin/segments.mdx +++ b/website/docs/reference/api/legacy/unleash/admin/segments.mdx @@ -12,11 +12,11 @@ import ApiRequest from '@site/src/components/ApiRequest'; export const basePath :::note -To use the admin API, you'll need to [create and use an admin API token](/how-to/how-to-create-api-tokens.mdx). +To use the admin API, you'll need to [create and use an admin API token](/how-to/how-to-create-api-tokens). ::: -The segments API lets you create, read, update, and delete [segments](/reference/segments.mdx). +The segments API lets you create, read, update, and delete [segments](/reference/segments). ## Get all segments @@ -330,18 +330,18 @@ This section describes the data objects returned by the endpoints in the segment :::note `values` and `value` -Some constraint operators only support single values. If a constraint uses one of these operators, the payload will contain a `value` property with the correct value. However, for backwards compatibility reasons, the payload will *also* contain a `values` property. If the operator accepts multiple values, the `value` property will not be present. Visit the [strategy constraints documentation](/reference/strategy-constraints.md) for more information on what operators support what number of values. +Some constraint operators only support single values. If a constraint uses one of these operators, the payload will contain a `value` property with the correct value. However, for backwards compatibility reasons, the payload will *also* contain a `values` property. If the operator accepts multiple values, the `value` property will not be present. Visit the [strategy constraints documentation](/reference/strategy-constraints) for more information on what operators support what number of values. ::: | Property | Type | Required | Description | Example value | |-------------------|-----------------------------------------------------------------------------------------------|----------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------| | `contextName` | string | Yes | The name of the context field targeted by the constraint. | `"myContextField"` | -| `operator` | string, the name of one of the [constraint operators](/reference/strategy-constraints.md) | Yes | The operator to apply to the context field. | `"DATE_BEFORE"` | +| `operator` | string, the name of one of the [constraint operators](/reference/strategy-constraints) | Yes | The operator to apply to the context field. | `"DATE_BEFORE"` | | `values` | a list of strings | Yes | The list of values to apply the constraint operator to. | `["value a", "value b"]` | | `value` | string | No | The value to apply the constraint operator to. | `"15"` | -| `inverted` | boolean | No | Whether the result of [the constraint will be negated or not](/reference/strategy-constraints.md#constraint-negation). | `false` | -| `caseInsensitive` | boolean string | No | Whether the constraint operator is case sensitive or not. Only [applies to some string-based operators](/reference/strategy-constraints.md#string-operators). | `false` | +| `inverted` | boolean | No | Whether the result of [the constraint will be negated or not](/reference/strategy-constraints#constraint-negation). | `false` | +| `caseInsensitive` | boolean string | No | Whether the constraint operator is case sensitive or not. Only [applies to some string-based operators](/reference/strategy-constraints#string-operators). | `false` | ### Activation strategy {#activation-strategy-type-description} diff --git a/website/docs/reference/api/legacy/unleash/index.md b/website/docs/reference/api/legacy/unleash/index.md index b8f87bc02f..0b126957b6 100644 --- a/website/docs/reference/api/legacy/unleash/index.md +++ b/website/docs/reference/api/legacy/unleash/index.md @@ -27,7 +27,7 @@ The internal API used by the Admin UI (unleash-frontend). Since v4.0.0 all opera With versions earlier than v4.0.0 and `insecure` authentication Basic Auth (with curl `-u myemail@test.com:`) is enough. -- [Events API](./admin/events.md) +- [Events API](./admin/events.mdx) - [Feature Flags API](./admin/features.md) - [Metrics API](./admin/metrics.md) - [Project API](./admin/projects.md) diff --git a/website/docs/reference/applications.mdx b/website/docs/reference/applications.mdx index 1347dc1b2d..666cc43c75 100644 --- a/website/docs/reference/applications.mdx +++ b/website/docs/reference/applications.mdx @@ -10,7 +10,7 @@ import Figure from '@site/src/components/Figure/Figure.tsx' ::: -An **application** is any service that sends requests to the [Unleash Client API](/reference/api/unleash/client), the [Unleash Frontend API](front-end-api.md), the Unleash Admin API, or any other API that Unleash exposes. This includes [Unleash SDKs](./sdks/index.md), [Unleash Edge](/docs/generated/unleash-edge.md), the [Unleash proxy](/docs/generated/unleash-proxy.md), and even the Admin UI. +An **application** is any service that sends requests to the [Unleash Client API](./api/unleash/client), the [Unleash Frontend API](./front-end-api), the Unleash Admin API, or any other API that Unleash exposes. This includes [Unleash SDKs](./sdks), [Unleash Edge](./unleash-edge), the [Unleash proxy](./unleash-proxy), and even the Admin UI. In the Admin UI, you can access Applications in **Configure > Applications**. diff --git a/website/docs/reference/change-requests.md b/website/docs/reference/change-requests.mdx similarity index 87% rename from website/docs/reference/change-requests.md rename to website/docs/reference/change-requests.mdx index 6eca6037a3..747100e523 100644 --- a/website/docs/reference/change-requests.md +++ b/website/docs/reference/change-requests.mdx @@ -82,7 +82,7 @@ When a scheduled change request is applied, the person who scheduled it and the If a change request contains changes that affect a flag that has been archived or a strategy that has been deleted, the change request can not be applied. Unleash will warn you ahead of time if you make changes that conflict with a scheduled change request. -Further, if a strategy, project segment, or [environment-level variant](feature-toggle-variants.md) configuration that is updated in a scheduled change request is updated before the scheduled application time (for instance by a different change request being applied or by updates that circumvent the change request flow), Unleash will suspend the scheduled change request. +Further, if a strategy, project segment, or [environment-level variant](feature-toggle-variants) configuration that is updated in a scheduled change request is updated before the scheduled application time (for instance by a different change request being applied or by updates that circumvent the change request flow), Unleash will suspend the scheduled change request. The reason for this is that the scheduled change request would overwrite the recent changes made to the strategy, segment, or environment variants. This could cause unwanted changes to occur, so we require you to take manual action. @@ -111,13 +111,13 @@ Unleash currently offers two distinct ways to schedule changes. Each method has The first method is through scheduled change requests, as we have explained in the preceding sections. Scheduled change requests make it easy to see all the changes across multiple flags and strategies in one view and makes it easy to reschedule or reject them. However, because scheduled changes rely on flags and strategy configurations, conflicts can arise causing the schedule to fail. -The second method uses Unleash's [constraints](strategy-constraints.md) and the [DATE_AFTER operator](strategy-constraints.md#date-and-time-operators) to encode when changes should take effect. The pros of this method is that because these changes can be applied immediately, you won't run into any conflicts when they happen. The cons are that you'll need to apply the same constraints to all the parts that you want to change and that there is no easy way to see all the changes in one view. You also can not scheduled changes to a segment in this way. When using this option, we recommend that you use [segments](segments.mdx) if you want to schedule multiple changes, so that their application time stays in sync. +The second method uses Unleash's [constraints](strategy-constraints) and the [DATE_AFTER operator](strategy-constraints#date-and-time-operators) to encode when changes should take effect. The pros of this method is that because these changes can be applied immediately, you won't run into any conflicts when they happen. The cons are that you'll need to apply the same constraints to all the parts that you want to change and that there is no easy way to see all the changes in one view. You also can not scheduled changes to a segment in this way. When using this option, we recommend that you use [segments](segments) if you want to schedule multiple changes, so that their application time stays in sync. Another important distinction is how these changes affect your connected SDKs. If you use constraints (or segments), then any connected SDK will be aware of the schedule ahead of time. That means that even if the SDK can not connect to Unleash at the scheduled time, it will still activate the changes because it's encoded in its constraints. On the other hand, if you use change requests to schedule changes, SDKs **must** update their configuration after the scheduled time to be aware of the changes. ## Change request permissions -Change requests have their own set of environment-specific permissions that can be applied to [custom project roles](rbac.md#custom-project-roles). These permissions let users +Change requests have their own set of environment-specific permissions that can be applied to [custom project roles](rbac#custom-project-roles). These permissions let users - approve/reject change requests - apply change requests @@ -125,9 +125,9 @@ Change requests have their own set of environment-specific permissions that can None of the predefined roles have any change request permissions, so you must create your own project roles to take advantage of change requests. In other words, even a user with the project "owner" role can not approve or apply change requests. -There is no permission to create change requests: **Anyone can create change requests**, even Unleash users with the [root viewer role](rbac.md#predefined-roles). Change requests don't cause any changes until approved and applied by someone with the correct permissions. +There is no permission to create change requests: **Anyone can create change requests**, even Unleash users with the [root viewer role](rbac#predefined-roles). Change requests don't cause any changes until approved and applied by someone with the correct permissions. -You can prevent non-project members from submitting change requests by setting a [protected project collaboration mode](project-collaboration-mode.md). +You can prevent non-project members from submitting change requests by setting a [protected project collaboration mode](project-collaboration-mode). ### Circumventing change requests @@ -149,24 +149,24 @@ Admin users will always see the change request UI so that they can test the chan ::: -Changes to project [segments](segments.mdx) (as opposed to global segments) also go through the change request process. This is to prevent a backdoor in the change request process. +Changes to project [segments](segments) (as opposed to global segments) also go through the change request process. This is to prevent a backdoor in the change request process. Since projects segments are not environment specific and change requests are always environment specific we allow to attach segment change to any environment with change requests enabled. -When you make changes though the Change Request UI it will automatically select first environment with change requests enabled, giving priority to [production](environments.md#environment-types) environments. +When you make changes though the Change Request UI it will automatically select first environment with change requests enabled, giving priority to [production](environments#environment-types) environments. Changes to segments can be only circumvented by admin users through the API calls. ## Change Request Preview Playground -To verify that a change request is correct, you can preview the result of change request's application in a change request [playground](playground.mdx). +To verify that a change request is correct, you can preview the result of change request's application in a change request [playground](playground). ![Change request preview](/img/change-request-preview.png) -From the change request overview page, go to the corresponding [playground](playground.mdx) and evaluate all your flags in the project and environment that your change request applies too. +From the change request overview page, go to the corresponding [playground](playground) and evaluate all your flags in the project and environment that your change request applies too. ![Change request playground evaluation](/img/change-request-playground-evaluation.png) -[Unleash context](playground.mdx#the-unleash-context) can be adjusted in the same way as in a regular playground, but the project and environment cannot be changed as they are derived from the change request itself. +[Unleash context](playground#the-unleash-context) can be adjusted in the same way as in a regular playground, but the project and environment cannot be changed as they are derived from the change request itself. Once the evaluation results confirm the changes in your change request are correct, go back to the change request overview and proceed with the approval or rejection. diff --git a/website/docs/reference/environments.md b/website/docs/reference/environments.md index 16f533295d..7ca73e8715 100644 --- a/website/docs/reference/environments.md +++ b/website/docs/reference/environments.md @@ -35,7 +35,7 @@ The other environment types do not currently have any functionality associated w ## Global and project-level environments -Environments exist on a global level, so they are available to all projects within Unleash. However, every [project](./projects.md) might not need to use every environment. That's why you can also choose which of the global environments should be available within a project. +Environments exist on a global level, so they are available to all projects within Unleash. However, every [project](./projects) might not need to use every environment. That's why you can also choose which of the global environments should be available within a project. ## How to start using environments diff --git a/website/docs/reference/feature-toggle-variants.md b/website/docs/reference/feature-toggle-variants.md index 8caa86e9cb..2224c61eb2 100644 --- a/website/docs/reference/feature-toggle-variants.md +++ b/website/docs/reference/feature-toggle-variants.md @@ -3,7 +3,7 @@ title: Feature Flag Variants (deprecated) --- :::warning -Feature Flag Variants at the environment level are deprecated in favor of the [strategy variants](./strategy-variants.md). +Feature Flag Variants at the environment level are deprecated in favor of the [strategy variants](./strategy-variants). Only features that have existing feature environment variants will keep them. If you'd like to keep the old variants in your hosted instance [contact us](https://slack.unleash.run) for further assistance. @@ -39,7 +39,7 @@ A variant has four components that define it: - an optional **override** - Overrides let you specify that certain users (as identified either by their user ID or by another [custom stickiness](./stickiness.md) value) will always get this variant, regardless of the variant's weight. + Overrides let you specify that certain users (as identified either by their user ID or by another [custom stickiness](./stickiness) value) will always get this variant, regardless of the variant's weight. ![A form for adding new variants. It has fields for name, weight, payload, and overrides.](/img/variant-creation-form.png 'Creating a new flag variant') @@ -100,7 +100,7 @@ The variant payload type provides hints to your application about how to parse t ### Variant stickiness -Variant stickiness is calculated on the received user and context, as described in [the stickiness chapter](./stickiness.md). This ensures that the same user will consistently see the same variant barring overrides and weight changes. If no context data is provided, the traffic will be spread randomly for each request. +Variant stickiness is calculated on the received user and context, as described in [the stickiness chapter](./stickiness). This ensures that the same user will consistently see the same variant barring overrides and weight changes. If no context data is provided, the traffic will be spread randomly for each request. ## How do I configure variants diff --git a/website/docs/reference/feature-toggles.mdx b/website/docs/reference/feature-toggles.mdx index a3bfe2ae66..578464dfb9 100644 --- a/website/docs/reference/feature-toggles.mdx +++ b/website/docs/reference/feature-toggles.mdx @@ -26,7 +26,7 @@ Activation strategies determine whether a feature flag activates for a specific ### Strategy variants -You can enhance your feature flags with [strategy variants](./strategy-variants.md). Feature flags let you define who gets access to a feature. With variants, you can also determine which version of the feature they see. +You can enhance your feature flags with [strategy variants](./strategy-variants). Feature flags let you define who gets access to a feature. With variants, you can also determine which version of the feature they see. For example, you might use variants to run an A/B testing experiment. Variants are defined by a name and weight, which determines the likelihood of each variant being shown. [Stickiness](./stickiness) ensures that users consistently see the same variant based on predefined parameters. @@ -61,7 +61,7 @@ To learn more, visit [Types of feature flags](../what-is-a-feature-flag#types-of A feature flag can have one of the following states: _active_, _potentially stale_, or _stale_. Unleash marks all flags as _potentially stale_ automatically once they pass their [expected lifetime](#expected-lifetime). -State gives you an indication of when to [clean up a feature flag in code](./technical-debt.md). +State gives you an indication of when to [clean up a feature flag in code](./technical-debt). You can also manually change the state on a feature flag's page by going to **Overview** and clicking **Toggle stale state**. @@ -127,7 +127,7 @@ If an archived feature is revived, it starts a new lifecycle with a new [initial **Plan**: [Pro](https://www.getunleash.io/pricing) and [Enterprise](https://www.getunleash.io/pricing) -**Unleash version**: `5.7+` | **Unleash Edge version**: `13.1+` | **Unleash Proxy version**: `0.18+`. Requires [SDK compatibility](../reference/sdks/index.md#server-side-sdk-compatibility-table) for variants. +**Unleash version**: `5.7+` | **Unleash Edge version**: `13.1+` | **Unleash Proxy version**: `0.18+`. Requires [SDK compatibility](../reference/sdks#server-side-sdk-compatibility-table) for variants. ::: Feature flag dependencies define a relationship between feature flags. Each feature flag can have one parent, but multiple child flags can share the same parent. diff --git a/website/docs/reference/impression-data.md b/website/docs/reference/impression-data.md index 38ece3d109..0236247fde 100644 --- a/website/docs/reference/impression-data.md +++ b/website/docs/reference/impression-data.md @@ -4,7 +4,7 @@ title: Impression Data :::note Availability -**Version**: `4.7+`. Requires [SDK compatibility](../reference/sdks/index.md#server-side-sdk-compatibility-table). +**Version**: `4.7+`. Requires [SDK compatibility](../reference/sdks#server-side-sdk-compatibility-table). ::: @@ -12,7 +12,7 @@ Unleash can provide you with **impression data** about the flags in your applica :::caution Front-end SDKs and disabled flags -Older versions of the front-end SDKs and other SDKs that connect the [Unleash proxy](../generated/unleash-proxy.md) or the [Unleash front-end API](../reference/front-end-api.md) would **not** emit impression events when a flag is disabled. +Older versions of the front-end SDKs and other SDKs that connect the [Unleash proxy](./unleash-proxy) or the [Unleash front-end API](./front-end-api) would **not** emit impression events when a flag is disabled. This is because impression data is a **per-flag** setting and the Proxy and front-end API only transmit information about flags that are enabled. As such, the SDK will never know that it should emit an impression event if a flag is disabled. @@ -20,7 +20,7 @@ Some of the front-end SDKs now include a include a configuration property that l ::: -Impression data was designed to make it easier for you to **collect analytics data**, **perform A/B tests**, and **enrich experiments** in your applications. It contains information about the feature flag and the related [Unleash Context](../reference/unleash-context.md). +Impression data was designed to make it easier for you to **collect analytics data**, **perform A/B tests**, and **enrich experiments** in your applications. It contains information about the feature flag and the related [Unleash Context](./unleash-context). Impression data is **opt-in on a per-flag basis**. Unleash will not emit impression events for flags not marked as such. Once you've turned impression data on for a flag, you can start listening for impression events in your client SDK. @@ -39,7 +39,7 @@ This table describes all the properties on the impression events: | --- | --- | --- | | `eventType` | The type of the event: `isEnabled` or `getVariant` | All | | `eventId` | A globally unique id (GUID) assigned to this event. | All | -| `context` | A representation of the current [Unleash Context](../reference/unleash-context.md). | All | +| `context` | A representation of the current [Unleash Context](./unleash-context). | All | | `enabled` | Whether the flag was enabled or not at when the client made the request. | All | | `featureName` | The name of the feature flag. | All | | `variant` | The name of the active variant | `getVariant` events only | @@ -81,13 +81,13 @@ This table describes all the properties on the impression events: Impression data is strictly an **opt-in** feature and must be enabled on a **per-flag basis**. You can enable and disable it both when you create a flag and when you edit a flag. -You can enable impression data via the impression data flag in the admin UI's flag creation form. You can also go via the [the API, using the `impressionData` option](/reference/api/legacy/unleash/admin/features-v2.md#create-toggle). For more detailed instructions, see [the section on enabling impression data in the how-to guide for capturing impression data](../how-to/how-to-capture-impression-data.mdx#step-1). +You can enable impression data via the impression data flag in the admin UI's flag creation form. You can also go via the [the API, using the `impressionData` option](/reference/api/legacy/unleash/admin/features-v2#create-toggle). For more detailed instructions, see [the section on enabling impression data in the how-to guide for capturing impression data](../how-to/how-to-capture-impression-data#step-1). ![A feature flag creation form. At the end of the form is a heading that says "Impression data", a short paragraph that describes the feature, and a flag to opt in or out of it.](/img/create_feat_impression.png) ## Example setup -The exact setup will vary depending on your [client SDK](../reference/sdks/index.md). The below example configures the [Unleash Proxy client../reference/sdks/javascript-browser) to listen for impression events and log them to the console. If "my-feature-flag" is configured to emit impression data, then it will trigger an impression event as soon as Unleash is ready. +The exact setup will vary depending on your [client SDK](./sdks). The below example configures the [Unleash Proxy client../reference/sdks/javascript-browser) to listen for impression events and log them to the console. If "my-feature-flag" is configured to emit impression data, then it will trigger an impression event as soon as Unleash is ready. ```js const unleash = new UnleashClient({ diff --git a/website/docs/reference/integrations/integrations.md b/website/docs/reference/integrations/integrations.mdx similarity index 79% rename from website/docs/reference/integrations/integrations.md rename to website/docs/reference/integrations/integrations.mdx index da98889f2c..346ae13951 100644 --- a/website/docs/reference/integrations/integrations.md +++ b/website/docs/reference/integrations/integrations.mdx @@ -18,12 +18,12 @@ Unleash has two types of integrations: Integrations that allow you to listen to Unleash currently supports the following integrations out of the box: -- [Datadog](datadog.md) - Allows Unleash to post Updates to Datadog when a feature flag is updated. -- [Jira Cloud](jira-cloud-plugin-usage.md) - Allows you to create, view and manage Unleash feature flags directly from a Jira Cloud issue -- [Jira Server](jira-server-plugin-usage.md) - Allows you to create and link Unleash feature flags directly from a Jira Server issue -- [Microsoft Teams](teams.md) - Allows Unleash to post updates to Microsoft Teams. -- [Slack App](slack-app.md) - The Unleash Slack App posts messages to the selected channels in your Slack workspace. -- [Webhook](webhook.md) - A generic way to post messages from Unleash to third party services. +- [Datadog](./integrations/datadog) - Allows Unleash to post Updates to Datadog when a feature flag is updated. +- [Jira Cloud](./integrations/jira-cloud-plugin-usage) - Allows you to create, view and manage Unleash feature flags directly from a Jira Cloud issue +- [Jira Server](./integrations/jira-server-plugin-usage) - Allows you to create and link Unleash feature flags directly from a Jira Server issue +- [Microsoft Teams](./integrations/teams) - Allows Unleash to post updates to Microsoft Teams. +- [Slack App](./integrations/slack-app) - The Unleash Slack App posts messages to the selected channels in your Slack workspace. +- [Webhook](./integrations/webhook) - A generic way to post messages from Unleash to third party services. :::tip Missing an integration? Request it! @@ -35,7 +35,7 @@ If you're looking for an integration that Unleash doesn't have at the moment, yo These integrations are deprecated and will be removed in a future release: -- [Slack](slack.md) - Allows Unleash to post updates to Slack. Please try the new [Slack App](slack-app.md) integration instead. +- [Slack](./integrations/slack) - Allows Unleash to post updates to Slack. Please try the new [Slack App](./integrations/slack-app) integration instead. ## Community integrations @@ -57,12 +57,12 @@ Integration events in Unleash provide a streamlined way to debug integrations by Integration events are logged for all outgoing integrations configured in Unleash. This includes integrations that send information from Unleash to other systems. Currently supported integrations include: - - [Datadog](./datadog.md) - - [Microsoft Teams](./teams.md) + - [Datadog](./integrations/datadog) + - [Microsoft Teams](./integrations/teams) - New Relic - - [Slack (deprecated)](./slack.md) - - [Slack App](./slack-app.md) - - [Webhook](./webhook.md) + - [Slack (deprecated)](./integrations/slack) + - [Slack App](./integrations/slack-app) + - [Webhook](./integrations/webhook) ### Viewing integration events diff --git a/website/docs/reference/integrations/jira-cloud-plugin-installation.md b/website/docs/reference/integrations/jira-cloud-plugin-installation.mdx similarity index 97% rename from website/docs/reference/integrations/jira-cloud-plugin-installation.md rename to website/docs/reference/integrations/jira-cloud-plugin-installation.mdx index b566e2bfba..072e25c183 100644 --- a/website/docs/reference/integrations/jira-cloud-plugin-installation.md +++ b/website/docs/reference/integrations/jira-cloud-plugin-installation.mdx @@ -26,7 +26,7 @@ You will need an Unleash admin user to configure the access tokens needed to con This plugin requires an Unleash Pro or an Unleash Enterprise instance. -We recommend using a [service account](../service-accounts.md) token for communicating with Unleash. Service accounts are also required to integrate with [Change Requests](../change-requests.md) +We recommend using a [service account](../service-accounts.md) token for communicating with Unleash. Service accounts are also required to integrate with [change requests](../change-requests) ### Jira diff --git a/website/docs/reference/integrations/jira-cloud-plugin-usage.md b/website/docs/reference/integrations/jira-cloud-plugin-usage.mdx similarity index 94% rename from website/docs/reference/integrations/jira-cloud-plugin-usage.md rename to website/docs/reference/integrations/jira-cloud-plugin-usage.mdx index 8cf181a154..50e5e399fa 100644 --- a/website/docs/reference/integrations/jira-cloud-plugin-usage.md +++ b/website/docs/reference/integrations/jira-cloud-plugin-usage.mdx @@ -2,6 +2,8 @@ title: Jira Cloud Integration - Usage --- +import Figure from '@site/src/components/Figure/Figure.tsx' + With the Unleash Jira Cloud Plugin you can create, view and manage Unleash feature flags directly from a Jira issue. The plugin also shows you current status of connected flags. @@ -42,7 +44,7 @@ from Jira. ### Change Requests -The plugin respects Unleash's [change requests](../change-requests.md). If change requests are turned on in the connected project and the selected environment, the plugin will ask whether you want to create a change request or not. +The plugin respects Unleash's [change requests](../change-requests). If change requests are turned on in the connected project and the selected environment, the plugin will ask whether you want to create a change request or not. If you already have an active change request for that project and that environment, the changes will be added to your existing change request. diff --git a/website/docs/reference/integrations/slack-app.md b/website/docs/reference/integrations/slack-app.mdx similarity index 100% rename from website/docs/reference/integrations/slack-app.md rename to website/docs/reference/integrations/slack-app.mdx diff --git a/website/docs/reference/integrations/slack.md b/website/docs/reference/integrations/slack.md index 6453aacf9f..124d6c808e 100644 --- a/website/docs/reference/integrations/slack.md +++ b/website/docs/reference/integrations/slack.md @@ -5,7 +5,7 @@ title: Slack (deprecated) :::caution Deprecation notice -This Slack integration is deprecated and will be removed in a future release. We recommend using the new [Slack App](./slack-app.md) integration instead. +This Slack integration is deprecated and will be removed in a future release. We recommend using the new [Slack App](./slack-app) integration instead. ::: diff --git a/website/docs/reference/network-view.mdx b/website/docs/reference/network-view.mdx index 0a1abd4e43..9bd6fa7e3d 100644 --- a/website/docs/reference/network-view.mdx +++ b/website/docs/reference/network-view.mdx @@ -20,7 +20,7 @@ The network view is intended to provide a simple and Unleash-centric overview th ## Applications -Both the network overview and the network traffic diagrams show you **applications** that have made requests to the Unleash instance. An **application** is defined as anything that sends requests to the [Unleash client API](/reference/api/unleash/client), the [Unleash front-end API](front-end-api.md), the Unleash admin API, or any other API that Unleash exposes. This includes [Unleash SDKs](./sdks/index.md), [Unleash Edge](/docs/generated/unleash-edge.md), the [Unleash proxy](/docs/generated/unleash-proxy.md), and even the admin UI. +Both the network overview and the network traffic diagrams show you **applications** that have made requests to the Unleash instance. An **application** is defined as anything that sends requests to the [Unleash client API](./api/unleash/client), the [Unleash front-end API](front-end-api), the Unleash admin API, or any other API that Unleash exposes. This includes [Unleash SDKs](./sdks), [Unleash Edge](./unleash-edge), the [Unleash proxy](./unleash-proxy), and even the admin UI. ### "unknown" applications @@ -66,7 +66,7 @@ This section will refer to the external source as Prometheus for simplicity. The network view uses an external Prometheus-like API to create diagrams. Because of this, Unleash will not enable the network view feature unless you set the `PROMETHEUS_API` environment variable. -The `PROMETHEUS_API` environment variable should point to the base path of the Prometheus installation, and Prometheus should be configured to get its data from Unleash's [internal backstage API](api/legacy/unleash/internal/prometheus.md). This can for example be done via a scraping job[^2]: +The `PROMETHEUS_API` environment variable should point to the base path of the Prometheus installation, and Prometheus should be configured to get its data from Unleash's [internal backstage API](api/legacy/unleash/internal/prometheus). This can for example be done via a scraping job[^2]: ```yaml title="Scraping job for Unleash metrics" - job_name: unleash_internal_metrics diff --git a/website/docs/reference/playground.mdx b/website/docs/reference/playground.mdx index 04646dd07f..38ed53316a 100644 --- a/website/docs/reference/playground.mdx +++ b/website/docs/reference/playground.mdx @@ -37,7 +37,7 @@ The playground will only evaluate features belonging to the projects you specify ### The Unleash context -The [Unleash context](../reference/unleash-context.md) represents a client SDK's configuration and used for evaluating your features. You can construct your own context or use a JSON version of a context from a client. +The [Unleash context](../reference/unleash-context) represents a client SDK's configuration and used for evaluating your features. You can construct your own context or use a JSON version of a context from a client. #### Multiple values for a single context field @@ -56,7 +56,7 @@ When you specify multiple values for context field, each value will be used to p You can add any fields you want to the context used for the evaluation, and you can also leave out any fields you want. However, there are some fields that will be set for you if don't provide them: - **`appName`**: Unleash clients all require an `appName` to start up. If you do not provide an `appName`, the playground will assign a default value to this property instead. -- **`currentTime`**: The `currentTime` property of the [Unleash context](../reference/unleash-context.md) gets auto-populated with the current time. You can override this manually by providing a value of your own. +- **`currentTime`**: The `currentTime` property of the [Unleash context](../reference/unleash-context) gets auto-populated with the current time. You can override this manually by providing a value of your own. ## The response @@ -68,11 +68,11 @@ In the UI, the playground displays the features in a table. Each row of the tabl
-Because you can add multiple values for each context field, each feature-environment cell contains the number of combinations that evaluated to `true` and `false` for the feature in the given environment. This can be expanded into a more detailed overview over what combinations of context fields evaluated to `true` and `false` along with any [variants](../reference/feature-toggle-variants.md). +Because you can add multiple values for each context field, each feature-environment cell contains the number of combinations that evaluated to `true` and `false` for the feature in the given environment. This can be expanded into a more detailed overview over what combinations of context fields evaluated to `true` and `false` along with any [variants](../reference/feature-toggle-variants).
-As with all of Unleash's client SDKs, the playground respects [stickiness](../reference/stickiness.md). The [stickiness algorithm](../reference/stickiness.md#calculation) guarantees that you'll always get the same variants and the same gradual rollout results if you provide the same context, as long as you provide the context field used for calculating stickiness. +As with all of Unleash's client SDKs, the playground respects [stickiness](../reference/stickiness). The [stickiness algorithm](../reference/stickiness#calculation) guarantees that you'll always get the same variants and the same gradual rollout results if you provide the same context, as long as you provide the context field used for calculating stickiness. ### The diff view @@ -108,14 +108,14 @@ There's currently two cases where the playground can't evaluate the strategy: 1. The [strategy is a custom strategy](#custom-strategies) and the playground doesn't have an implementation for the strategy. 2. The [strategy is the 'Application Hostname' strategy](#application-hostname). -Even if the playground doesn't recognize or otherwise can't evaluate a specific strategy, it _may_ still evaluate the overall strategy result to `false` (and be certain that it is the right result). If a strategy has [constraints](../reference/strategy-constraints.md) or [segments](segments.mdx) that are not satisfied, the playground knows that the strategy result wouldn't be `true`, regardless of the actual strategy implementation. As such, if a strategy can't be evaluated, it can be **either** _unknown_ or _`false`_. +Even if the playground doesn't recognize or otherwise can't evaluate a specific strategy, it _may_ still evaluate the overall strategy result to `false` (and be certain that it is the right result). If a strategy has [constraints](../reference/strategy-constraints) or [segments](segments) that are not satisfied, the playground knows that the strategy result wouldn't be `true`, regardless of the actual strategy implementation. As such, if a strategy can't be evaluated, it can be **either** _unknown_ or _`false`_. ### Custom Strategies -The playground does not have any implementations for [custom strategies](../reference/custom-activation-strategies.md) and adding custom strategy implementations to Unleash is not currently supported. Because of this, custom strategies will never be evaluated as `true`. +The playground does not have any implementations for [custom strategies](../reference/custom-activation-strategies) and adding custom strategy implementations to Unleash is not currently supported. Because of this, custom strategies will never be evaluated as `true`. ### The Application Hostname strategy {#application-hostname} -The [application hostname strategy](../reference/activation-strategies.md#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/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. 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/project-collaboration-mode.md b/website/docs/reference/project-collaboration-mode.md index 10cd7b2691..99e897a5f6 100644 --- a/website/docs/reference/project-collaboration-mode.md +++ b/website/docs/reference/project-collaboration-mode.md @@ -12,9 +12,9 @@ title: Project Collaboration Mode Project collaboration modes allow you to manage project visibility and interaction levels, ensuring better control and collaboration within your organization. -The collaboration mode of a [project](projects.md) defines who within your Unleash instance can access the project. This setting also determines who can submit [change requests](change-requests.md)–a feature that provides controlled and secure updates for feature flags. +The collaboration mode of a [project](./projects) defines who within your Unleash instance can access the project. This setting also determines who can submit [change requests](./change-requests)–a feature that provides controlled and secure updates for feature flags. -Unleash supports three collaboration modes: **open**, **protected**, and **private**. A user's [predefined root and project roles](rbac.md#predefined-roles), as well as their [custom root roles](rbac.md#custom-root-roles), determine what projects they can access. +Unleash supports three collaboration modes: **open**, **protected**, and **private**. A user's [predefined root and project roles](./rbac#predefined-roles), as well as their [custom root roles](./rbac#custom-root-roles), determine what projects they can access. ## Open collaboration mode @@ -28,7 +28,7 @@ All users of your Unleash instance can view the project but only project Members ## Private collaboration mode -Only project Members, Admins, Editors, and users with [custom root roles](rbac.md#custom-root-roles) can view the project. Viewers, who are not project Members, can't see the project in the project list. Only project Members and Admins can submit change requests. +Only project Members, Admins, Editors, and users with [custom root roles](./rbac#custom-root-roles) can view the project. Viewers, who are not project Members, can't see the project in the project list. Only project Members and Admins can submit change requests. | | View project | Submit change requests | @@ -39,7 +39,7 @@ Only project Members, Admins, Editors, and users with [custom root roles](rbac.m # Set project collaboration mode -To [create a new project](projects.md#create-a-project) with a specific collaboration mode, do the following: +To [create a new project](./projects#create-a-project) with a specific collaboration mode, do the following: 1. In the Unleash Admin UI, go to **Projects** > **New project**. 2. Enter **Project name**. 3. Click **Open** to choose your collaboration mode. diff --git a/website/docs/reference/projects.md b/website/docs/reference/projects.mdx similarity index 73% rename from website/docs/reference/projects.md rename to website/docs/reference/projects.mdx index dbf1314897..22ee9c95d1 100644 --- a/website/docs/reference/projects.md +++ b/website/docs/reference/projects.mdx @@ -9,9 +9,9 @@ Projects help you organize feature flags within Unleash. For example, you can us Each instance requires at least one project. New instances get a default project that all members can access. You cannot delete this project, but you can [rename](#update-a-project) or [archive it](#archive-a-project). -You can configure which [environments](environments.md) are available within a project. By default, all global environments are available. You can only enable and disable feature flags for the environments you've configured for the project. +You can configure which [environments](./environments) are available within a project. By default, all global environments are available. You can only enable and disable feature flags for the environments you've configured for the project. -By default, projects have an open [collaboration mode](project-collaboration-mode.md), which means all members of your instance can access the project and submit change requests. To learn more, visit [Project Collaboration Mode](project-collaboration-mode.md). +By default, projects have an open [collaboration mode](./project-collaboration-mode), which means all members of your instance can access the project and submit change requests. To learn more, visit [Project Collaboration Mode](./project-collaboration-mode). ## Create a project @@ -23,7 +23,7 @@ By default, projects have an open [collaboration mode](project-collaboration-mod To create a new project: 1. Go to **Projects** > **New project** and enter a project name. -2. Optionally configure settings such as [environments](environments.md), [stickiness](stickiness.md), [collaboration mode](project-collaboration-mode.md), and [change requests](change-requests.md). +2. Optionally configure settings such as [environments](./environments), [stickiness](./stickiness), [collaboration mode](./project-collaboration-mode), and [change requests](./change-requests). 3. Click **Create project**. @@ -37,9 +37,9 @@ To create a new project: You can update all aspects of a project except its ID. -To update a project, go to **Projects** and select the project you'd like to edit. In the **Project settings** tab, you can update general settings such as project name, description, [stickiness](stickiness.md), [collaboration mode](project-collaboration-mode.md), and more. You can also configure user and API access, [change requests](change-requests.md), and [actions](actions.md), add [segments](segments.mdx) and [environments](environments.md), and update the [default strategy](#project-default-strategy). +To update a project, go to **Projects** and select the project you'd like to edit. In the **Project settings** tab, you can update general settings such as project name, description, [stickiness](./stickiness), [collaboration mode](./project-collaboration-mode), and more. You can also configure user and API access, [change requests](./change-requests), and [actions](./actions), add [segments](./segments) and [environments](./environments), and update the [default strategy](#project-default-strategy). -The available project settings depend on a user's [root and project roles](rbac.md). +The available project settings depend on a user's [root and project roles](./rbac). ## Archive a project @@ -51,7 +51,7 @@ The available project settings depend on a user's [root and project roles](rbac. The archive projects functionality allows you to hide a project while maintaining historical project data. Archiving lets you manage short-lived projects, for example, to represent specific initiatives in your organization. -Before archiving a project, you must archive all feature flags within it. Archiving automatically disables all project [actions](actions.md). Once you archive a project, you cannot add or move feature flags to it. +Before archiving a project, you must archive all feature flags within it. Archiving automatically disables all project [actions](./actions). Once you archive a project, you cannot add or move feature flags to it. To archive a project: @@ -100,9 +100,9 @@ import Figure from '@site/src/components/Figure/Figure.tsx' ::: -Each project has a default strategy of [gradual rollout](activation-strategies.md#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#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. -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.md) and adding [segments](segments.mdx), [constraints](strategy-constraints.md), and [variants](strategy-variants.md). +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](./strategy-constraints), and [variants](./strategy-variants). To change the default strategy for an environment in a project: diff --git a/website/docs/reference/rbac.md b/website/docs/reference/rbac.md index 103a1c8463..fb1dd2c007 100644 --- a/website/docs/reference/rbac.md +++ b/website/docs/reference/rbac.md @@ -148,7 +148,7 @@ Custom project roles let you define your own project roles with a specific set o environment level. The roles can then be assigned to users in specific projects. All users have viewer access to all projects and resources, but must be assigned a project role to be allowed to edit a project's resources. For a step-by-step walkthrough of how to create and assign custom project roles, see [_how to create and assign custom project -roles_](../how-to/how-to-create-and-assign-custom-project-roles.md). +roles_](../how-to/how-to-create-and-assign-custom-project-roles). Each custom project role consists of: @@ -190,9 +190,9 @@ You can assign the following permissions on a per-environment level within the p | **delete activation strategies** | Lets the user delete feature flag activation strategies within the environment. | | **enable/disable flags** | Lets the user enable and disable flags within the environment. | | **update variants** | Lets the user create, edit and remove variants within the environment. | -| **approve a change request** | Lets the user approve [change requests](change-requests.md) in the environment. | +| **approve a change request** | Lets the user approve [change requests](./change-requests) in the environment. | | **apply a change request** | Lets the user apply change requests in the environment. | -| **skip change requests** | Lets the user ignore change request requirements. This applies **only when using the API** directly; when using the admin UI, users with this permission will still need to go through the normal change request flow. You can find more details in the section on [circumventing change requests](change-requests.md#circumventing-change-requests). | +| **skip change requests** | Lets the user ignore change request requirements. This applies **only when using the API** directly; when using the admin UI, users with this permission will still need to go through the normal change request flow. You can find more details in the section on [circumventing change requests](./change-requests#circumventing-change-requests). | ## Multiple Project Roles diff --git a/website/docs/reference/resource-limits.mdx b/website/docs/reference/resource-limits.mdx index 6906bca8e6..f62700e9ab 100644 --- a/website/docs/reference/resource-limits.mdx +++ b/website/docs/reference/resource-limits.mdx @@ -15,22 +15,22 @@ To ensure that Unleash operates smoothly, it includes resource limits for some o The resources and their respective limits and environment variables are: -| Resource | OSS limit | Pro limit | Enterprise limit | Environment variable | -|-----------------------------------------------------------------|----------:|----------:|-----------------:|------------------------------------------------| -| [Feature flags](feature-toggles.mdx)[^1] | 5,000 | 5,000 | 50,000 | `UNLEASH_FEATURE_FLAGS_LIMIT` | -| [Strategies](activation-strategies.md) per flag per environment | 30 | 30 | 30 | `UNLEASH_FEATURE_ENVIRONMENT_STRATEGIES_LIMIT` | -| [Constraints](strategy-constraints.md) per strategy | 30 | 30 | 30 | `UNLEASH_CONSTRAINTS_LIMIT` | -| Values per [constraint](strategy-constraints.md) | 250 | 250 | 1,000 | `UNLEASH_CONSTRAINT_VALUES_LIMIT` | -| [Segments](segments.mdx) | 300 | 300 | 300 | `UNLEASH_SEGMENTS_LIMIT` | -| [API tokens](api-tokens-and-client-keys.mdx) | 2,000 | 2,000 | 2,000 | `UNLEASH_API_TOKENS_LIMIT` | -| [Projects](projects.md) | 1 | 3 | 500 | `UNLEASH_PROJECTS_LIMIT` | -| [Environments](environments.md) | 2 | 2 | 50 | `UNLEASH_ENVIRONMENTS_LIMIT` | -| [Signal](signals.md) endpoints | N/A | N/A | 5 | `UNLEASH_SIGNAL_ENDPOINTS_LIMIT` | -| [Signal](signals.md) tokens per endpoint | N/A | N/A | 5 | `UNLEASH_SIGNAL_TOKENS_PER_ENDPOINT_LIMIT` | -| [Action](actions.md) set actions | N/A | N/A | 10 | `UNLEASH_ACTION_SET_ACTIONS_LIMIT` | -| [Action](actions.md) sets per project | N/A | N/A | 5 | `UNLEASH_ACTION_SETS_PER_PROJECT_LIMIT` | -| [Action](actions.md) set filters | N/A | N/A | 5 | `UNLEASH_ACTION_SET_FILTERS_LIMIT` | -| [Action](actions.md) set filter values | N/A | N/A | 25 | `UNLEASH_ACTION_SET_FILTER_VALUES_LIMIT` | +| Resource | OSS limit | Pro limit | Enterprise limit | Environment variable | +|----------------------------------------------------------------|----------:|----------:|-----------------:|------------------------------------------------| +| [Feature flags](./feature-toggles)[^1] | 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](./strategy-constraints) per strategy | 30 | 30 | 30 | `UNLEASH_CONSTRAINTS_LIMIT` | +| Values per [constraint](./strategy-constraints) | 250 | 250 | 1,000 | `UNLEASH_CONSTRAINT_VALUES_LIMIT` | +| [Segments](./segments) | 300 | 300 | 300 | `UNLEASH_SEGMENTS_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` | +| [Signal](./signals) endpoints | N/A | N/A | 5 | `UNLEASH_SIGNAL_ENDPOINTS_LIMIT` | +| [Signal](./signals) tokens per endpoint | N/A | N/A | 5 | `UNLEASH_SIGNAL_TOKENS_PER_ENDPOINT_LIMIT` | +| [Action](./actions) set actions | N/A | N/A | 10 | `UNLEASH_ACTION_SET_ACTIONS_LIMIT` | +| [Action](./actions) sets per project | N/A | N/A | 5 | `UNLEASH_ACTION_SETS_PER_PROJECT_LIMIT` | +| [Action](./actions) set filters | N/A | N/A | 5 | `UNLEASH_ACTION_SET_FILTERS_LIMIT` | +| [Action](./actions) set filter values | N/A | N/A | 25 | `UNLEASH_ACTION_SET_FILTER_VALUES_LIMIT` | ## Overriding the limits diff --git a/website/docs/reference/sdks/index.md b/website/docs/reference/sdks/index.mdx similarity index 87% rename from website/docs/reference/sdks/index.md rename to website/docs/reference/sdks/index.mdx index 47ae1522fc..71a82b94f1 100644 --- a/website/docs/reference/sdks/index.md +++ b/website/docs/reference/sdks/index.mdx @@ -73,31 +73,31 @@ 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](../reference/activation-strategies#standard) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | -| [Gradual rollout](../reference/activation-strategies#gradual-rollout) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | -| [Gradual rollout: custom stickiness](../reference/activation-strategies#customize-stickiness-beta) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | -| [UserID](../reference/activation-strategies#userids) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | -| [IP](../reference/activation-strategies#ips) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | -| [IP](../reference/activation-strategies#ips): CIDR syntax | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | ✅ | ✅ | -| [Hostname](../reference/activation-strategies#hostnames) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | -| **Category: [Custom strategies](../custom-activation-strategies.md)** | | | | | | | | | +| [Standard](./activation-strategies#standard) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | +| [Gradual rollout](./activation-strategies#gradual-rollout) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | +| [Gradual rollout: custom stickiness](./activation-strategies#customize-stickiness-beta) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | +| [UserID](./activation-strategies#userids) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | +| [IP](./activation-strategies#ips) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | +| [IP](./activation-strategies#ips): CIDR syntax | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | ✅ | ✅ | +| [Hostname](./activation-strategies#hostnames) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | +| **Category: [Custom strategies](./custom-activation-strategies)** | | | | | | | | | | Basic support | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | -| **Category: [Strategy constraints](../strategy-constraints.md)** | | | | | | | | | +| **Category: [Strategy constraints](./strategy-constraints)** | | | | | | | | | | Basic support (`IN`, `NOT_IN` operators) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | Advanced support (Semver, date, numeric, and extended string operators) (introduced in) | ✅ (5.1) | ✅ (3.12) | ✅ (3.3) | ✅ (5.1) | ✅ (4.2) | ✅ (2.1) | ✅ (1.3.1) | ⭕ | -| **Category: [Unleash Context](../reference/unleash-context)** | | | | | | | | | +| **Category: [Unleash Context](./unleash-context)** | | | | | | | | | | Static fields (`environment`, `appName`) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | Defined fields | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | Custom properties | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | -| **Category: [`isEnabled`](../client-specification#implementation-of-isenabled)** | | | | | | | | | +| **Category: [`isEnabled`](./client-specification#implementation-of-isenabled)** | | | | | | | | | | Can take context | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | Override fallback value | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | Fallback function | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | ⭕ | ⭕ | -| **Category: [Variants](../feature-toggle-variants.md)** | | | | | | | | | +| **Category: [Variants](./feature-toggle-variants)** | | | | | | | | | | Basic support | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | Custom fallback variant | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | | Custom weight | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | -| [Custom stickiness](../stickiness.md#custom-stickiness-beta) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | +| [Custom stickiness](./stickiness#custom-stickiness-beta) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | | [Strategy Variants](./strategy-variants)| ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | | **Category: Local backup** | | | | | | | | | | File-based backup | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | @@ -105,7 +105,7 @@ If you see an item marked with a ❌ that you would find useful, feel free to re | Can disable metrics | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | Client registration | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | | Basic usage metrics (yes/no) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | -| [Impression data](../impression-data.md) | ✅ | ✅ | ⭕ | ✅ | ⭕ | ⭕ | ✅ | ⭕ | +| [Impression data](./impression-data) | ✅ | ✅ | ⭕ | ✅ | ⭕ | ⭕ | ✅ | ⭕ | | **Category: Bootstrap (beta)** | | | | | | | | | | Bootstrap from file | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | | Custom Bootstrap implementation | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ | @@ -138,7 +138,7 @@ Here's some of the fantastic work our community has done to make Unleash work in If you can't find an SDK that fits your requirements, you can also develop your own SDK. To make implementation easier, check out these resources: - [Unleash Client Specifications](https://github.com/Unleash/client-specification) - Used by all official SDKs to make sure they behave correctly across different language implementations. This lets us verify that a gradual rollout to 10% of the users would affect the same users regardless of which SDK you're using. -- [Client SDK overview](../client-specification) - A brief, overall guide of the _Unleash Architecture_ and important aspects of the SDK role in it all. +- [Client SDK overview](./client-specification) - A brief, overall guide of the _Unleash Architecture_ and important aspects of the SDK role in it all. ## Client-side SDK behavior diff --git a/website/docs/reference/segments.mdx b/website/docs/reference/segments.mdx index c0c6344b2e..2c9fb4a0c8 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](../reference/strategy-constraints.md). Like with strategy constraints, you apply segments to [feature flag activation strategies](../reference/activation-strategies.md). +A **segment** is a reusable collection of [strategy constraints](./strategy-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.md#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-request-for-segments "change requests for segments") settings. ## Structure and evaluation @@ -52,23 +52,23 @@ In theory, you could create segments with a thousand constraints, each with a mi By default, you can apply **at most 5 segments to any one strategy**. Separate strategies (even on the same feature) do not count towards the same total, so you can have two strategies with 5 segments each. -You **can** [configure segment limits](/using-unleash/deploy/configuring-unleash.md#segments) with environment variables. +You **can** [configure segment limits](./using-unleash/deploy/configuring-unleash#segments) with environment variables. ### A note on large segments {#large-segments} Segments are just constraints, so any limitations that apply to constraints also apply to segments. -This means that if you want to add a hundred different user IDs to one of your constraints, you are most likely better off thinking about finding another way to solve this problem. That may be using a different abstraction or finding another pattern that you can use instead. Refer to the section on [constraint limitations](../reference/strategy-constraints.md#limitations) for a more thorough explanation or to [the topic guide on using Unleash with large constraints](../understanding-unleash/managing-constraints.mdx) for a more thorough . +This means that if you want to add a hundred different user IDs to one of your constraints, you are most likely better off thinking about finding another way to solve this problem. That may be using a different abstraction or finding another pattern that you can use instead. Refer to the section on [constraint limitations](../reference/strategy-constraints#limitations) for a more thorough explanation or to [the topic guide on using Unleash with large constraints](../understanding-unleash/managing-constraints) for a more thorough . ## Creating, updating, and deleting segments :::info -Currently in development, Unleash will soon count segments as being in use when they are used in [change requests](change-requests.md). +Currently in development, Unleash will soon count segments as being in use when they are used in [change requests](./change-requests). ::: -Segments can be created, edited, and deleted from the segments page in the admin UI or via the API (see the [segments API documentation](/reference/api/legacy/unleash/admin/segments.mdx)). +Segments can be created, edited, and deleted from the segments page in the admin UI or via the API (see the [segments API documentation](/reference/api/legacy/unleash/admin/segments)). A segment that is in use cannot be deleted. If you'd like to delete a segment that is in use, you must first remove the segment from all the activation strategies that are currently using it. If a segment is in use by an archived flag, you must either unarchive the flag and remove the segment or delete the flag entirely before the segment can be deleted. diff --git a/website/docs/reference/sso.md b/website/docs/reference/sso.md index d977d41623..7dc8cc2a49 100644 --- a/website/docs/reference/sso.md +++ b/website/docs/reference/sso.md @@ -21,8 +21,8 @@ In order to configure Single-Sign-On you will need to log in to the Unleash inst Unleash enterprise supports multiple authentication providers. -- [OpenID Connect with Okta](../how-to/how-to-add-sso-open-id-connect.md) -- [SAML 2.0 with Okta](../how-to/how-to-add-sso-saml.md) -- [SAML 2.0 with Keycloak](../how-to/how-to-add-sso-saml-keycloak.md) -- [SAML 2.0 with Microsoft Entra ID](../how-to/how-to-add-sso-azure-saml.md) -- [Google Authentication](../how-to/how-to-add-sso-google.md) (deprecated) +- [OpenID Connect with Okta](../how-to/how-to-add-sso-open-id-connect) +- [SAML 2.0 with Okta](../how-to/how-to-add-sso-saml) +- [SAML 2.0 with Keycloak](../how-to/how-to-add-sso-saml-keycloak) +- [SAML 2.0 with Microsoft Entra ID](../how-to/how-to-add-sso-azure-saml) +- [Google Authentication](../how-to/how-to-add-sso-google) (deprecated) diff --git a/website/docs/reference/stickiness.md b/website/docs/reference/stickiness.md index 4b2f091102..2e436d2665 100644 --- a/website/docs/reference/stickiness.md +++ b/website/docs/reference/stickiness.md @@ -14,17 +14,17 @@ 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.md#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#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. ## Custom stickiness {#custom-stickiness} :::note Availability -**Plan**: [Enterprise](https://www.getunleash.io/pricing) | **Version**: `4.0+` and [SDK compatibility](../reference/sdks/index.md#server-side-sdk-compatibility-table). +**Plan**: [Enterprise](https://www.getunleash.io/pricing) | **Version**: `4.0+` and [SDK compatibility](../reference/sdks#server-side-sdk-compatibility-table). ::: -When using [the gradual rollout strategy](../reference/activation-strategies.md#gradual-rollout) or [feature flag variants](./feature-toggle-variants.md), 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.md) as long as you have enabled custom stickiness for these fields. +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. ### Enabling custom stickiness @@ -43,7 +43,7 @@ To enable custom stickiness on a field, navigate to the Create Context screen in Each project in Unleash can have its own default stickiness context field. Whenever you add a gradual rollout strategy or variants to a feature in that project, Unleash will use the configured context field as the initial value. -Only context fields that have the [custom stickiness](unleash-context.md#custom-stickiness) option turned on can be used as default stickiness fields. +Only context fields that have the [custom stickiness](unleash-context#custom-stickiness) option turned on can be used as default stickiness fields. If you don't specify a default custom stickiness, the project will use the "default" stickiness option, which works as described in the [calculation section](#calculation). diff --git a/website/docs/reference/strategy-constraints.md b/website/docs/reference/strategy-constraints.mdx similarity index 96% rename from website/docs/reference/strategy-constraints.md rename to website/docs/reference/strategy-constraints.mdx index f3c2180491..94d59f5f80 100644 --- a/website/docs/reference/strategy-constraints.md +++ b/website/docs/reference/strategy-constraints.mdx @@ -30,7 +30,7 @@ You can constrain both on [standard context fields](../reference/unleash-context Unleash SDKs expect all context values to be strings. If you use an operator that acts on non-string values, such as [numeric operators](#numeric-operators) or [date and time operators](#date-and-time-operators), the SDK will attempt to convert the string into the expected type. If the conversion fails, the constraint will evaluate to `false`. ::: -This page explains what strategy constraints are in Unleash and how they work. If you want to know *how you add* strategy constraints to an activation strategy, see [the corresponding how-to guide](../how-to/how-to-add-strategy-constraints.md "how to add strategy constraints"). +This page explains what strategy constraints are in Unleash and how they work. If you want to know *how you add* strategy constraints to an activation strategy, see [the corresponding how-to guide](../how-to/how-to-add-strategy-constraints). @@ -38,7 +38,7 @@ This page explains what strategy constraints are in Unleash and how they work. I ## Constraining on custom context fields :::info Making custom context fields available -To be able to constrain on a field, it must be listed under the Context Field menu. If a field isn't listed, you can add it yourself. See [the how-to guide for creating your own custom fields](../how-to/how-to-define-custom-context-fields.md) for more info. +To be able to constrain on a field, it must be listed under the Context Field menu. If a field isn't listed, you can add it yourself. See [the how-to guide for creating your own custom fields](../how-to/how-to-define-custom-context-fields) for more info. ::: Unleash only provides a limited set of context fields by default, and they may not fulfill all your needs. @@ -75,7 +75,7 @@ To clarify, here's a few example strategy constraints and what they do: In this section, `` is used as a placeholder for an arbitrary context field. With the exception of the `currentTime` field, you can use any context field in its place. ::: -Unleash supports a wide range of constraint operators. `IN` and `NOT_IN` are basic operators that are available in all versions and SDKs. All other operators require Unleash version 4.9+ and [SDK compatibility](../reference/sdks/index.md#strategy-constraints). +Unleash supports a wide range of constraint operators. `IN` and `NOT_IN` are basic operators that are available in all versions and SDKs. All other operators require Unleash version 4.9+ and [SDK compatibility](../reference/sdks#strategy-constraints). ### Constraint negation / inversion {#constraint-negation} @@ -174,7 +174,7 @@ Additionally, you can use negation to get _less than or equal to_ and _greater t This section gives a brief overview over to use the client SDKs to interact with strategy constraints. The exact steps will vary depending on which client you are using, so make sure to consult the documentation for your specific client SDK. ::: -Strategy constraints require [the Unleash Context](../reference/unleash-context) to work. All official [Unleash client SDKs](../reference/sdks/index.md) support the option to pass [dynamic context values](../reference/unleash-context#structure "Unleash Context, section: structure") to the `isEnabled` function (or the SDK's equivalent). +Strategy constraints require [the Unleash Context](../reference/unleash-context) to work. All official [Unleash client SDKs](../reference/sdks) support the option to pass [dynamic context values](../reference/unleash-context#structure) to the `isEnabled` function (or the SDK's equivalent). If the strategy constraint uses a [**standard Unleash Context field**](../reference/unleash-context#structure), set the context field to the value you wish to give it. @@ -188,7 +188,7 @@ This value can still be negated as explained in [the section on negating values] :::tip -Explore the content in this subsection in more depth in [the topic guide on using Unleash with large constraints](/understanding-unleash/managing-constraints.mdx). +Explore the content in this subsection in more depth in [the topic guide on using Unleash with large constraints](/understanding-unleash/managing-constraints). ::: @@ -209,12 +209,12 @@ If you use the new constraints with old SDKs, here's how it'll affect _some_ of - The Python client SDK will evaluate the flag to false, as it cannot evaluate the constraint successfully. - The .NET, Ruby, and PHP SDKs raise exceptions if the provided operator is not `IN` or `NOT_IN`. -Please inspect the [SDK compatibility table to see which version of your preferred SDK introduced support for this feature](../reference/sdks/index.md#strategy-constraints). +Please inspect the [SDK compatibility table to see which version of your preferred SDK introduced support for this feature](../reference/sdks#strategy-constraints). After Unleash 4.9, we updated the [Unleash client specification](https://github.com/Unleash/client-specification). Going forward, any constraint that a client does not recognize, **must be evaluated as `false`** ## [Deprecated]: Constrain on a specific environment {#constrain-on-a-specific-environment} -Before Unleash 4.3, using strategy constraints was the recommended way to have different flag configurations per environment. Now that Unleash has environment support built in, we no longer recommend you use strategy constraints for this. Instead, see the [environments documentation](../reference/environments.md). +Before Unleash 4.3, using strategy constraints was the recommended way to have different flag configurations per environment. Now that Unleash has environment support built in, we no longer recommend you use strategy constraints for this. Instead, see the [environments documentation](../reference/environments). [^1]: `userScore` is not a default Unleash field, but can be added as a [custom context field](../reference/unleash-context#custom-context-fields). diff --git a/website/docs/reference/strategy-variants.md b/website/docs/reference/strategy-variants.mdx similarity index 100% rename from website/docs/reference/strategy-variants.md rename to website/docs/reference/strategy-variants.mdx diff --git a/website/docs/reference/unleash-context.md b/website/docs/reference/unleash-context.md index 80d7cef22d..ed84cacb95 100644 --- a/website/docs/reference/unleash-context.md +++ b/website/docs/reference/unleash-context.md @@ -2,7 +2,7 @@ title: Unleash Context --- -The **Unleash Context** contains information relating to the current feature flag request. Unleash uses this context to evaluate [activation strategies](activation-strategies.md) and [strategy constraints](../reference/strategy-constraints.md) and to calculate [flag stickiness](../reference/stickiness.md). The Unleash Context is an important feature of all the [Unleash client SDKs](../reference/sdks/index.md). +The **Unleash Context** contains information relating to the current feature flag request. Unleash uses this context to evaluate [activation strategies](activation-strategies) and [strategy constraints](../reference/strategy-constraints) and to calculate [flag stickiness](../reference/stickiness). The Unleash Context is an important feature of all the [Unleash client SDKs](../reference/sdks). ## Structure @@ -12,7 +12,7 @@ You can group the Unleash Context fields into two separate groups based on how t **Dynamic** fields, however, can change with every request. You'll typically provide these when checking whether a flag is enabled in your client. -_All fields are optional_, but some strategies depend on certain fields being present. For instance, [the UserIDs strategy](activation-strategies.md#userids) requires that the `userId` field is present on the Context. +_All fields are optional_, but some strategies depend on certain fields being present. For instance, [the UserIDs strategy](activation-strategies#userids) requires that the `userId` field is present on the Context. The below table gives a brief overview over what the fields' intended usage is, their lifetime, and their type. Note that the exact type can vary between programming languages and implementations. Be sure to consult your specific client SDK for more information on its implementation of the Unleash Context. @@ -29,7 +29,7 @@ The below table gives a brief overview over what the fields' intended usage is, ### The `properties` field -The `properties` field is different from the others. You can use the `properties` field to provide arbitrary data to [custom strategies](../reference/custom-activation-strategies.md) or to [strategy constraints](../reference/strategy-constraints.md). The `properties` field is also where you add values for [custom context fields](#custom-context-fields). +The `properties` field is different from the others. You can use the `properties` field to provide arbitrary data to [custom strategies](../reference/custom-activation-strategies) or to [strategy constraints](../reference/strategy-constraints). The `properties` field is also where you add values for [custom context fields](#custom-context-fields). #### A note on properties and constraints @@ -48,7 +48,7 @@ For operators that work on non-string types, such as numeric and date time opera ::: -Custom context fields allow you to extend the Unleash Context with more data that is applicable to your situation. Each context field definition consists of a name and an optional description. Additionally, you can choose to define a set of [_legal values_](#legal-values "legal values for custom context fields"), and you can choose whether or not the context field can be used in [custom stickiness calculations](../reference/stickiness.md#custom-stickiness) for the [gradual rollout strategy](activation-strategies.md#customize-stickiness-beta) and for [feature flag variants](../reference/feature-toggle-variants.md). +Custom context fields allow you to extend the Unleash Context with more data that is applicable to your situation. Each context field definition consists of a name and an optional description. Additionally, you can choose to define a set of [_legal values_](#legal-values "legal values for custom context fields"), and you can choose whether or not 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). 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. @@ -63,7 +63,7 @@ You can update custom context fields after they have been created. You can chang By using the **legal values** option when creating a context field, you can create a set of valid options for a context field's values. If a context field has a defined set of legal values, the Unleash Admin UI will only allow users to enter one or more of the specified values. If a context field _doesn't_ have any defined legal values, the user can enter whatever they want. -Using a custom context field called _region_ as an example: if you define the field's legal values as _Africa_, _Asia_, _Europe_, and _North America_, then you would only be allowed to use one or more of those four values when using the custom context field as a [strategy constraint](../reference/strategy-constraints.md). +Using a custom context field called _region_ as an example: if you define the field's legal values as _Africa_, _Asia_, _Europe_, and _North America_, then you would only be allowed to use one or more of those four values when using the custom context field as a [strategy constraint](../reference/strategy-constraints). ![A strategy constraint form with a constraint set to "region". The "values" input is a dropdown menu containing the options "Africa", "Asia", "Europe", and "North America", as defined in the preceding paragraph.](/img/constraints_legal_values.png) @@ -71,14 +71,14 @@ Using a custom context field called _region_ as an example: if you define the fi :::note SDK compatibility -Custom stickiness is supported by all of our SDKs except for the Rust SDK. You can always refer to the [SDK compatibility table](../reference/sdks/index.md#server-side-sdk-compatibility-table) for the full overview. +Custom stickiness is supported by all of our SDKs except for the Rust SDK. You can always refer to the [SDK compatibility table](../reference/sdks#server-side-sdk-compatibility-table) for the full overview. ::: -Any context field _can_ be used to [calculate custom stickiness](../reference/stickiness.md#custom-stickiness). However, you need to explicitly tell Unleash that you want a field to be used for custom stickiness for it to be possible. You can enable this functionality either when you create the context field or at any later point. For steps on how to do this, see [the _How to define custom context fields_ guide](../how-to/how-to-define-custom-context-fields). +Any context field _can_ be used to [calculate custom stickiness](../reference/stickiness#custom-stickiness). However, you need to explicitly tell Unleash that you want a field to be used for custom stickiness for it to be possible. You can enable this functionality either when you create the context field or at any later point. For steps on how to do this, see [the _How to define custom context fields_ guide](../how-to/how-to-define-custom-context-fields). -[^1]: If you're on Unleash 4.3 or higher, you'll probably want to use [the environments feature](../reference/environments.md) instead of relying on the `environment` context field when working with environments. +[^1]: If you're on Unleash 4.3 or higher, you'll probably want to use [the environments feature](../reference/environments) instead of relying on the `environment` context field when working with environments. -[^2]: Check the [*strategy constraints: advanced support* row of the compatibility table](../reference/sdks/index.md#strategy-constraints-advanced-support) for an overview of which SDKs provide the `currentTime` property. +[^2]: Check the [*strategy constraints: advanced support* row of the compatibility table](../reference/sdks#strategy-constraints-advanced-support) for an overview of which SDKs provide the `currentTime` property. diff --git a/website/docs/reference/whats-new-v4.md b/website/docs/reference/whats-new-v4.md index dc7b1d2815..27a8340f2c 100644 --- a/website/docs/reference/whats-new-v4.md +++ b/website/docs/reference/whats-new-v4.md @@ -6,7 +6,7 @@ Version 4 of Unleash brings a lot of improvements to Unleash. In this document w ### Upgrade with ease {#upgrade-with-ease} -Unleash can either be hosted by us or self-hosted. If you have a managed Unleash Enterprise instance you are automatically upgraded to version 4. If you manage Unleash yourself (either Open-Source or Enterprise Self-hosted) we recommend reading the [migration guide](../using-unleash/deploy/upgrading-unleash.md). +Unleash can either be hosted by us or self-hosted. If you have a managed Unleash Enterprise instance you are automatically upgraded to version 4. If you manage Unleash yourself (either Open-Source or Enterprise Self-hosted) we recommend reading the [migration guide](../using-unleash/deploy/upgrading-unleash). **PS! The first time you access Unleash v4 from a self-hosted instance you will need to login with the default admin user:** @@ -17,16 +17,16 @@ _(We recommend changing the password of the default user from the admin section. ### Role-Based Access Control {#role-based-access-control} -With Role-Based Access Control you can now assign groups to users in order to control access. You can control access to root resources in addition to controlling access to [projects](projects.md). _Please be aware that all existing users will become "Owner" of all existing projects as part of the migration from v3 to v4._ +With Role-Based Access Control you can now assign groups to users in order to control access. You can control access to root resources in addition to controlling access to [projects](./projects). _Please be aware that all existing users will become "Owner" of all existing projects as part of the migration from v3 to v4._ -[Read more](rbac.md) +[Read more](./rbac) ### New Integrations {#new-integrations} Integrations make it easy to integrate Unleash with other systems. In version 4 we bring two new integrations to Unleash: -- [Microsoft Teams](../reference/integrations/teams.md) -- [Datadog](../reference/integrations/datadog.md) +- [Microsoft Teams](../reference/integrations/teams) +- [Datadog](../reference/integrations/datadog) ### Improved UX {#improved-ux} @@ -40,15 +40,15 @@ In version 4 we added support for [OpenID Connect](https://openid.net/connect/) In version 4 we improved the User Management and made it available for Unleash Open-Source and Unleash Enterprise. Starting in v4 all users accessing Unleash needs to exist in Unleash in order to gain access (because they need to have the proper permission from RBAC.) -[Read more](../how-to/how-to-add-users-to-unleash.md) +[Read more](../how-to/how-to-add-users-to-unleash) ### API access {#api-access} In version 4 we improved the API Access and made it available for Unleash Open-Source and Unleash Enterprise. Starting from Unleash v4 we require all SDKs to use an access token in order to connect to Unleash. -[Read more](../how-to/how-to-use-the-admin-api.md) +[Read more](../how-to/how-to-use-the-admin-api) ### Custom stickiness {#custom-stickiness} In Unleash Enterprise v4 you can configure stickiness when you are -doing a gradual rollout with the "gradual rollout" strategy (previously known as "flexible rollout") or together with feature flag variants. This means that you can now have consistent behavior based on any field available on the [Unleash context](unleash-context.md). +doing a gradual rollout with the "gradual rollout" strategy (previously known as "flexible rollout") or together with feature flag variants. This means that you can now have consistent behavior based on any field available on the [Unleash context](./unleash-context). diff --git a/website/docs/topics/concepts/what-is-a-feature-flag.md b/website/docs/topics/concepts/what-is-a-feature-flag.mdx similarity index 98% rename from website/docs/topics/concepts/what-is-a-feature-flag.md rename to website/docs/topics/concepts/what-is-a-feature-flag.mdx index c88a559965..6434659be4 100644 --- a/website/docs/topics/concepts/what-is-a-feature-flag.md +++ b/website/docs/topics/concepts/what-is-a-feature-flag.mdx @@ -148,7 +148,7 @@ Contrary to the short-lived nature of most feature flags, kill switches are inhe Operational flags manage a system’s technical aspects that do not directly influence user-visible features but are crucial for the application’s underlying stability and performance. For example, during a library version upgrade, operational flags can toggle between the old and new implementations to ensure the update does not adversely affect the system. By enabling real-time switching between different operational states or configurations, these flags allow for thorough validation of changes in a live environment without disrupting the user experience. -Operational flags should be short-lived, existing only long enough to confirm that a change, such as a library update, is stable and does not introduce regressions. Once the new state is validated, the flag should be promptly retired to avoid accumulating technical debt. Avoid using operational flags as a solution for long-term configuration management; see our [Best practices for building and scaling feature flags](../feature-flags/feature-flag-best-practices.md) guide to learn more. +Operational flags should be short-lived, existing only long enough to confirm that a change, such as a library update, is stable and does not introduce regressions. Once the new state is validated, the flag should be promptly retired to avoid accumulating technical debt. Avoid using operational flags as a solution for long-term configuration management; see our [Best practices for building and scaling feature flags](./topics/feature-flags/feature-flag-best-practices) guide to learn more. ### Permission flags @@ -213,6 +213,6 @@ Unleash is on a mission to make developers’ lives easier. Individual developer If you want to learn more about how to implement feature flags at scale, check out the following resources: - [Feature Flag Tutorials](/feature-flag-tutorials) -- [Best practices for using feature flags at scale](../feature-flags/best-practices-using-feature-flags-at-scale.md) -- [Best practices for building and scaling feature flags](../feature-flags/feature-flag-best-practices.md) +- [Best practices for using feature flags at scale](./topics/feature-flags/best-practices-using-feature-flags-at-scale) +- [Best practices for building and scaling feature flags](./topics/feature-flags/feature-flag-best-practices) - [Try Unleash for Free](https://www.getunleash.io/pricing) \ No newline at end of file diff --git a/website/docs/topics/feature-flags/best-practices-using-feature-flags-at-scale.md b/website/docs/topics/feature-flags/best-practices-using-feature-flags-at-scale.mdx similarity index 95% rename from website/docs/topics/feature-flags/best-practices-using-feature-flags-at-scale.md rename to website/docs/topics/feature-flags/best-practices-using-feature-flags-at-scale.mdx index 09f5e2ceea..c45d70cd46 100644 --- a/website/docs/topics/feature-flags/best-practices-using-feature-flags-at-scale.md +++ b/website/docs/topics/feature-flags/best-practices-using-feature-flags-at-scale.mdx @@ -6,7 +6,7 @@ import Figure from '@site/src/components/Figure/Figure.tsx' “A feature flag is just an if statement,” you say. This is true in a way, but when your organization has thousands of developers, each managing dozens or hundreds of flags with complex targeting rules and audit trails across dozens of microservices-based applications, those if statements can quickly become complex. This is especially true if you don’t set up your system correctly in the first place. -This guide to using feature flag systems at scale is based on lessons learned working with some of the largest feature flag deployments in the world through the [Unleash Open-Source](https://github.com/Unleash/unleash) and [Enterprise Feature Management platform](https://www.getunleash.io/enterprise-feature-management-platform). However, the principles outlined do not apply only to Unleash. They apply to any large-scale feature flag system, including one you build yourself or another commercial solution. For tips on how to stand up and run a feature flag system, see our [principles for building and scaling feature flags](feature-flag-best-practices.md). +This guide to using feature flag systems at scale is based on lessons learned working with some of the largest feature flag deployments in the world through the [Unleash Open-Source](https://github.com/Unleash/unleash) and [Enterprise Feature Management platform](https://www.getunleash.io/enterprise-feature-management-platform). However, the principles outlined do not apply only to Unleash. They apply to any large-scale feature flag system, including one you build yourself or another commercial solution. For tips on how to stand up and run a feature flag system, see our [principles for building and scaling feature flags](./feature-flag-best-practices). This guide is organized into three sections that align with the stages of a large-scale feature flag rollout: @@ -68,7 +68,7 @@ Modern applications are composed of multiple services with many complex dependen Just because a user might need to interact with a flag does not mean you should display it by default when it is outside your main organizational parameters. However, all flags should be easily searchable. When a user finds one, they should be able to inspect its configuration and ownership so that they might request additional permissions or [submit change requests for approval](#6-implement-flag-approval-workflows-early). -This is why feature flag systems should be [open by default](feature-flag-best-practices.md#9-choose-open-by-default-democratize-feature-flag-access). There are valid use cases for excluding flags from global search. For example, a public company in the middle of an acquisition where exposing flags related to the website or app changes might breach regulatory guidelines. Your feature flag system should accommodate these private projects; however, they should be the exception, not the rule. +This is why feature flag systems should be [open by default](./feature-flag-best-practices#9-choose-open-by-default). There are valid use cases for excluding flags from global search. For example, a public company in the middle of an acquisition where exposing flags related to the website or app changes might breach regulatory guidelines. Your feature flag system should accommodate these private projects; however, they should be the exception, not the rule. ### 3. Design for flag permissions to change over time. @@ -192,7 +192,7 @@ Here are a few examples of functionality managed by feature flags and where you When building new (often complex) features for users, systems require changes across multiple parts – modules within an application or services in a microservices architecture. While it's tempting to use a single feature flag to control all these changes and evaluate it locally in each module, we recommend against it for a few reasons: - Unpredictable Timing: User requests flow through the system and touch different parts as they progress. Between each invocation, time passes. Even with perfectly synchronized feature flags, requests will hit different system parts at slightly different times. This means the flag state could change between evaluations, leading to inconsistent behavior for the user. -- Laws of distributed computing: Particularly in distributed systems, we cannot assume all parts of the system are perfectly synchronized, as networks are unreliable and can experience transient errors at any time. Feature flag systems generally [prefer availability over consistency](feature-flag-best-practices.md#6-design-for-failure-favor-availability-over-consistency). By only evaluating a feature flag once, we guarantee a consistent experience for our users. +- Laws of distributed computing: Particularly in distributed systems, we cannot assume all parts of the system are perfectly synchronized, as networks are unreliable and can experience transient errors at any time. Feature flag systems generally [prefer availability over consistency](./feature-flag-best-practices#6-prioritize-availability-over-consistency). By only evaluating a feature flag once, we guarantee a consistent experience for our users. - Violates Single Responsibility: Using the same flag in multiple locations spreads feature control logic throughout your codebase, violating the single-responsibility principle. We find that companies are usually more successful when using feature flags when they can protect new complex features with a single flag evaluated only once per user request. This approach ensures consistent behavior and simplifies long-term code maintainability. @@ -245,7 +245,7 @@ To keep complexity down, we generally advise not to have complex targeting rules Both feature flags and configuration settings control an application’s behavior. However, it's crucial to distinguish between feature flagging systems and configuration management systems and use each for its intended purpose. Otherwise, you risk management nightmares and security vulnerabilities -Feature flags are intended for dynamic and temporary use, giving you [runtime control](feature-flag-best-practices.md#1-enable-run-time-control-control-flags-dynamically-not-using-config-files) to enable or disable functionality in a live environment. This flexibility supports [short-lived experiments](feature-flag-best-practices.md#7-make-feature-flags-short-lived-do-not-confuse-flags-with-application-configuration), such as A/B testing or gradual rollouts, instead of relying on configuration settings that require an application redeploy to take effect. Despite the ease of turning off and on features or functionality with feature flags, they should not be repurposed for managing configuration. +Feature flags are intended for dynamic and temporary use, giving you [runtime control](./feature-flag-best-practices#1-enable-runtime-control) to enable or disable functionality in a live environment. This flexibility supports [short-lived experiments](./feature-flag-best-practices#7-make-flags-short-lived), such as A/B testing or gradual rollouts, instead of relying on configuration settings that require an application redeploy to take effect. Despite the ease of turning off and on features or functionality with feature flags, they should not be repurposed for managing configuration. A dedicated config management system should manage long-term configuration settings. These systems are designed to handle sensitive information such as API keys and access credentials securely, unlike feature flag systems, which typically do not encrypt flag states. Misusing feature flags for configuration can lead to security risks and management complexities. @@ -341,4 +341,4 @@ Feature flags are a powerful tool for delivering software efficiently while main Remember, the key to successful feature flag management at scale lies in clear processes, regular maintenance, and a commitment to best practices. With these in place, you can leverage feature flags to drive innovation and improve your software development lifecycle. -This guide was all about using feature flags at scale. For similar tips on building and scaling the feature flag system itself, see our [feature flag best practices guide](feature-flag-best-practices.md). +This guide was all about using feature flags at scale. For similar tips on building and scaling the feature flag system itself, see our [feature flag best practices guide](./feature-flag-best-practices). diff --git a/website/docs/topics/feature-flags/feature-flag-best-practices.md b/website/docs/topics/feature-flags/feature-flag-best-practices.mdx similarity index 100% rename from website/docs/topics/feature-flags/feature-flag-best-practices.md rename to website/docs/topics/feature-flags/feature-flag-best-practices.mdx diff --git a/website/docs/understanding-unleash/managing-constraints.mdx b/website/docs/understanding-unleash/managing-constraints.mdx index f1a97a2dd4..e74b064a20 100644 --- a/website/docs/understanding-unleash/managing-constraints.mdx +++ b/website/docs/understanding-unleash/managing-constraints.mdx @@ -8,7 +8,7 @@ In this explanatory guide, we will discuss how best to deal with large and compl ::: -Unleash offers several ways to limit feature exposure to a specified audience, such as the [User IDs strategy](../reference/activation-strategies.md#userids), [strategy constraints](../reference/strategy-constraints.md), and [segments](../reference/segments.mdx). Each of these options makes it easy to add some sort of user identifier to the list of users who should get access to a feature. +Unleash offers several ways to limit feature exposure to a specified audience, such as the [User IDs strategy](../reference/activation-strategies#userids), [strategy constraints](../reference/strategy-constraints), and [segments](../reference/segments). Each of these options makes it easy to add some sort of user identifier to the list of users who should get access to a feature. Because of their availability and ease of use with smaller lists, it can be tempting to just keep adding identifiers to those lists. However, once you start approaching a hundred elements, we recommend that you find another way to manage these IDs. In fact, it's probably better to stop well before you get that far. @@ -18,7 +18,7 @@ How large is too large? How complex is too complex? It depends. However, smaller ## The cost of data -First, let's talk a bit about Unleash's architecture: **Your Unleash instance** is where you define all your features, their strategies, and constraints (and a lot more). However, the Unleash instance itself does not do any of the feature evaluation[^1]. That responsibility is delegated to the Unleash SDKs (or [Edge](/generated/unleash-edge.md) / the [Unleash proxy](/generated/unleash-proxy.md)). +First, let's talk a bit about Unleash's architecture: **Your Unleash instance** is where you define all your features, their strategies, and constraints (and a lot more). However, the Unleash instance itself does not do any of the feature evaluation[^1]. That responsibility is delegated to the Unleash SDKs (or [Edge](../reference/unleash-edge) / the [Unleash proxy](../reference/unleash-proxy)). For the SDKs (Edge/proxy included) to evaluate a feature, it needs to know everything about that feature in a specific environment. This includes all strategies and their constraints. This means that the Unleash instance must transmit all information about this feature (and all other features) as a response to an API call. @@ -32,7 +32,7 @@ In other words: it's not good. Okay, so putting all these IDs in Unleash isn't good. But how **do** you manage features for these 124 special cases you have? -The first thing to think about would be whether you can group these special cases in some way. Maybe you already have an [Unleash context](../reference/unleash-context.md) field that covers the same amount of users. In that case, you can constrain that instead. If you don't have a context field that matches these users, then you might need to create one. +The first thing to think about would be whether you can group these special cases in some way. Maybe you already have an [Unleash context](../reference/unleash-context) field that covers the same amount of users. In that case, you can constrain that instead. If you don't have a context field that matches these users, then you might need to create one. Further, if you have a lot of special cases and require complex constraint logic to model it correctly, this probably reflects some logic that is specific to your domain. It's also likely that this same logic is used elsewhere in your system external to Unleash. Modeling this logic in multiple places can quickly lead to breakage, and we recommend having a single source of truth for cases like this. @@ -52,4 +52,4 @@ An option is to set up an external data store that handles this information spec The Unleash SDKs are designed to be fast and unobtrusive. This means that resolving a large set of constraints at runtime results in one of two problems: either the SDK needs to resolve very large amounts of data, which can put pressure on your network or it needs to make a potentially slow network call to resolve the segment. Both of these are undesirable for the health of your application. -[^1]: Well, except for in the case of the [front-end API](../reference/front-end-api.md). But even then, the size of the data to transmit matters. +[^1]: Well, except for in the case of the [front-end API](../reference/front-end-api). But even then, the size of the data to transmit matters. diff --git a/website/docs/understanding-unleash/the-anatomy-of-unleash.mdx b/website/docs/understanding-unleash/the-anatomy-of-unleash.mdx index ad739aa2b9..066ee050f1 100644 --- a/website/docs/understanding-unleash/the-anatomy-of-unleash.mdx +++ b/website/docs/understanding-unleash/the-anatomy-of-unleash.mdx @@ -4,7 +4,7 @@ title: The Anatomy of Unleash import Figure from "@site/src/components/Figure/Figure.tsx"; -This guide's purpose is to give you a conceptual overview of how Unleash works. It covers the various components that exist within our system and how they interact with each other and with external applications. The diagrams help you understand the fundamental building blocks, such as [projects](../reference/projects.md), [environments](../reference/environments.md), [variants](../reference/feature-toggle-variants.md) and of course, [feature flags](../reference/feature-toggles.mdx). +This guide's purpose is to give you a conceptual overview of how Unleash works. It covers the various components that exist within our system and how they interact with each other and with external applications. The diagrams help you understand the fundamental building blocks, such as [projects](../reference/projects), [environments](../reference/environments), [variants](../reference/strategy-variants) and of course, [feature flags](../reference/feature-toggles). The end of this guide presents a [short use case, explaining how you might configure Unleash](#use-case) to start working with feature flags. @@ -12,17 +12,17 @@ The end of this guide presents a [short use case, explaining how you might confi Some things in Unleash are configured and defined on the root level. These options apply across the entire Unleash instance. The most important root configuration options for day-to-day operations are: -- [API access tokens](../reference/api-tokens-and-client-keys.mdx) -- [Projects](../reference/projects.md) -- [Segments](../reference/segments.mdx) -- [Strategy types](../reference/activation-strategies.md) (including [custom activation strategy types](../reference/custom-activation-strategies.md)) -- [Tag types](../reference/tags.md) -- [Unleash context](../reference/unleash-context.md) fields (including [custom context fields](../reference/unleash-context.md#custom-context-fields)) -- Users, [user groups](../reference/rbac.md#user-groups) and [roles](../reference/rbac.md) +- [API access tokens](../reference/api-tokens-and-client-keys) +- [Projects](../reference/projects) +- [Segments](../reference/segments) +- [Strategy types](../reference/activation-strategies) (including [custom activation strategy types](../reference/custom-activation-strategies)) +- [Tag types](../reference/tags) +- [Unleash context](../reference/unleash-context) fields (including [custom context fields](../reference/unleash-context#custom-context-fields)) +- Users, [user groups](../reference/rbac#user-groups) and [roles](../reference/rbac) ## Projects -[**Projects**](../reference/projects.md) contain [feature flags](../reference/feature-toggles.mdx) and their configurations, and a set of active [environments](../reference/environments.md). +[**Projects**](../reference/projects) contain [feature flags](../reference/feature-toggles) and their configurations, and a set of active [environments](../reference/environments). All Unleash instances must have at least one project at any given time. New instances get a project called “Default”. @@ -41,7 +41,7 @@ Pro and Enterprise customers can create, rename, and delete projects as they wis caption="Feature flags can be activated or deactivated independently in different environments. For instance, a feature flag can be active in the development environment, and deactivated in the production environment. Even if their configuration is otherwise identical, deactivated feature flags will never be considered enabled." /> -[**Environments**](../reference/environments.md) in Unleash let you change how a feature flag works in your application’s different environments. For instance, while you are developing a feature, it’s likely that you’ll want it to be available in your development environment, but not in your production environment: environments let you do that. You might also want to enable a feature for only some users in your development environment, but no users in your production environment: environments let you do that. +[**Environments**](../reference/environments) in Unleash let you change how a feature flag works in your application’s different environments. For instance, while you are developing a feature, it’s likely that you’ll want it to be available in your development environment, but not in your production environment: environments let you do that. You might also want to enable a feature for only some users in your development environment, but no users in your production environment: environments let you do that. Environments exist on two different levels within Unleash. The set of **all available environments is defined on the root level**. Additionally, **each project** can choose which of these root environments should be **available on the project level**. The set of environments available to any given project is **always a subset** of the set of all available environments at the root level. @@ -49,7 +49,7 @@ Each project must always have **at least one** active environment. Enterprise users can create and remove environments. Open-source and Pro customers get access to two environments: **development** and **production.** -Environments are adjacent to [feature flags](../reference/feature-toggles.mdx) in Unleash: neither one contains the other, but they come together to let you define activation strategies. +Environments are adjacent to [feature flags](../reference/feature-toggles) in Unleash: neither one contains the other, but they come together to let you define activation strategies.
-[**Activation strategies**](../reference/activation-strategies.md) (or just **strategies** for short) are the part of feature flags that tell Unleash **who should get a feature**. An activation strategy is assigned to **one **feature flag in **one **environment. +[**Activation strategies**](../reference/activation-strategies) (or just **strategies** for short) are the part of feature flags that tell Unleash **who should get a feature**. An activation strategy is assigned to **one **feature flag in **one **environment. -When you check a [feature flag](../reference/feature-toggles.mdx) in an application, the following decides the result: +When you check a [feature flag](../reference/feature-toggles) in an application, the following decides the result: 1. Is the flag active in the current environment? If not, it will be disabled. 2. If the flag **is** active in the current environment, the flag’s strategies decide the result. As long as **at least one** of a flag’s strategies resolves to `true` for the current context (user or application), then the flag will be considered enabled. In other words, if you have a hundred strategies and ninety-nine of them resolve to false, but one of them resolves to true, then the flag is enabled. -Activation strategies tie feature flags and [environments](../reference/environments.md) together. When you assign an activation strategy to a feature flag, you do so in one environment at a time. You can assign the same strategy to the same flag in different environments, but they will be different instances of the same strategy and do not stay in sync. Unleash also lets you copy strategies from one environment to another. +Activation strategies tie feature flags and [environments](../reference/environments) together. When you assign an activation strategy to a feature flag, you do so in one environment at a time. You can assign the same strategy to the same flag in different environments, but they will be different instances of the same strategy and do not stay in sync. Unleash also lets you copy strategies from one environment to another. -Unleash comes with a number of [built-in strategies](../reference/activation-strategies.md). You can also create your own [custom activation strategies](../reference/custom-activation-strategies.md). All strategies can be further augmented by [**strategy constraints**](../reference/strategy-constraints.md). +Unleash comes with a number of [built-in strategies](../reference/activation-strategies). You can also create your own [custom activation strategies](../reference/custom-activation-strategies). All strategies can be further augmented by [**strategy constraints**](../reference/strategy-constraints).