website/docs: pushing to share sidebar mess

website/.gitignore

@@ -22,4 +22,4 @@ yarn-error.log*
 
 static/docker-compose.yml
 static/schema.yaml
-developer-docs/api/reference/**
+docs/developer-docs/api/reference/**

website/docs/applications/index.md → website/docs/add-secure-apps/applications/index.md

@@ -35,7 +35,7 @@ The following aspects can be configured:
 
     If the authentik server does not have a volume mounted under `/media`, you'll get a text input. This accepts absolute URLs. If you've mounted single files into the container, you can reference them using `https://authentik.company/media/my-file.png`.
 
-    If there is a mount under `/media` or if [S3 storage](../installation/storage-s3.md) is configured, you'll instead see a field to upload a file.
+    If there is a mount under `/media` or if [S3 storage](../../install-config/storage-s3.md) is configured, you'll instead see a field to upload a file.
 
 -   _Publisher_: Text shown below the application
 -   _Description_: Subtext shown on the application card below the publisher

website/docs/flow/context/index.md → website/docs/add-secure-apps/flows-stages/flow/context/index.md

@@ -22,15 +22,15 @@ Keys prefixed with `goauthentik.io` are used internally by authentik and are sub
 
 ### Common keys
 
-#### `pending_user` ([User object](../../user-group-role/user/user_ref.md#object-properties))
+#### `pending_user` ([User object](../../../../users-sources/user/user_ref.md#object-properties))
 
-`pending_user` is used by multiple stages. In the context of most flow executions, it represents the data of the user that is executing the flow. This value is not set automatically, it is set via the [Identification stage](../stages/identification/).
+`pending_user` is used by multiple stages. In the context of most flow executions, it represents the data of the user that is executing the flow. This value is not set automatically, it is set via the [Identification stage](../../stages/identification/index.md).
 
-Stages that require a user, such as the [Password stage](../stages/password/), the [Authenticator validation stage](../stages/authenticator_validate/) and others will use this value if it is set, and fallback to the request's users when possible.
+Stages that require a user, such as the [Password stage](../../stages/password/index.md), the [Authenticator validation stage](../../stages/authenticator_validate/index.md) and others will use this value if it is set, and fallback to the request's users when possible.
 
 #### `prompt_data` (Dictionary)
 
-`prompt_data` is primarily used by the [Prompt stage](../stages/prompt/). The value of any field within a prompt stage is written to the `prompt_data` dictionary. For example, given a field with the _Field key_ `email` that was submitted with the value `foo@bar.baz` will result in the following context:
+`prompt_data` is primarily used by the [Prompt stage](../../stages/prompt/index.md). The value of any field within a prompt stage is written to the `prompt_data` dictionary. For example, given a field with the _Field key_ `email` that was submitted with the value `foo@bar.baz` will result in the following context:
 
 ```json
 {
@@ -40,7 +40,7 @@ Stages that require a user, such as the [Password stage](../stages/password/), t
 }
 ```
 
-This data can be modified with policies. The data is also used by stages like [User write](../stages/user_write.md), which takes data in `prompt_data` and writes it to `pending_user`.
+This data can be modified with policies. The data is also used by stages like [User write](../../stages/user_write.md), which takes data in `prompt_data` and writes it to `pending_user`.
 
 #### `redirect` (string)
 
@@ -62,7 +62,7 @@ When a user authenticates/enrolls via an external source, this will be set to th
 
 #### `outpost` (dictionary) <span class="badge badge--info">authentik 2024.10+</span>
 
-When a flow is executed by an Outpost (for example the [LDAP](../../providers/ldap/index.md) or [RADIUS](../../providers/radius/index.mdx)), this will be set to a dictionary containing the Outpost instance under the key `"instance"`.
+When a flow is executed by an Outpost (for example the [LDAP](../../../providers/ldap/index.md) or [RADIUS](../../../providers/radius/index.mdx)), this will be set to a dictionary containing the Outpost instance under the key `"instance"`.
 
 ### Scenario-specific keys
 
@@ -72,7 +72,7 @@ Set to `True` when the flow is executed from an "SSO" context. For example, this
 
 #### `is_restored` (Token object)
 
-Set when a flow execution is continued from a token. This happens for example when an [Email stage](../stages/email/index.mdx) is used and the user clicks on the link within the email. The token object contains the key that was used to restore the flow execution.
+Set when a flow execution is continued from a token. This happens for example when an [Email stage](../../stages/email/index.mdx) is used and the user clicks on the link within the email. The token object contains the key that was used to restore the flow execution.
 
 ### Stage-specific keys
 
@@ -126,9 +126,9 @@ Optionally overwrite the deny message shown, has a higher priority than the mess
 
 #### User write stage
 
-##### `groups` (List of [Group objects](../../user-group-role/groups/index.mdx))
+##### `groups` (List of [Group objects](../../../../users-sources/groups/index.mdx))
 
-See [Group](../../user-group-role/groups/index.mdx). If set in the flow context, the `pending_user` will be added to all the groups in this list.
+See [Group](../../../../users-sources/groups/index.mdx). If set in the flow context, the `pending_user` will be added to all the groups in this list.
 
 If set, this must be a list of group objects and not group names.
 
@@ -148,11 +148,11 @@ Type the `pending_user` will be created as. Must be one of `internal`, `external
 
 ##### `user_backend` (string)
 
-Set by the [Password stage](../stages/password/index.md) after successfully authenticating in the user. Contains a dot-notation to the authentication backend that was used to successfully authenticate the user.
+Set by the [Password stage](../../stages/password/index.md) after successfully authenticating in the user. Contains a dot-notation to the authentication backend that was used to successfully authenticate the user.
 
 ##### `auth_method` (string)
 
-Set by the [Password stage](../stages/password/index.md), the [Authenticator validation stage](../stages/authenticator_validate/index.md), the [OAuth2 Provider](../../providers/oauth2/index.md), and the API authentication depending on which method was used to authenticate.
+Set by the [Password stage](../../stages/password/index.md), the [Authenticator validation stage](../../stages/authenticator_validate/index.md), the [OAuth2 Provider](../../../providers/oauth2/index.md), and the API authentication depending on which method was used to authenticate.
 
 Possible options:
 
@@ -161,7 +161,7 @@ Possible options:
 -   `ldap` (Authenticated via LDAP bind from an LDAP source)
 -   `auth_mfa` (Authentication via MFA device without password)
 -   `auth_webauthn_pwl` (Passwordless authentication via WebAuthn)
--   `jwt` ([M2M](../../providers/oauth2/client_credentials.md) authentication via an existing JWT)
+-   `jwt` ([M2M](../../../providers/oauth2/client_credentials.md) authentication via an existing JWT)
 
 ##### `auth_method_args` (dictionary)
 

website/docs/flow/executors/headless.md → website/docs/add-secure-apps/flows-stages/flow/executors/headless.md

@@ -6,6 +6,6 @@ The headless flow executor is used by clients that don't have access to the web
 
 The following stages are supported:
 
--   [**Identification stage**](../stages/identification/)
--   [**Password stage**](../stages/password/)
--   [**Authenticator Validation Stage**](../stages/authenticator_validate/)
+-   [**Identification stage**](../../stages/identification/index.md)
+-   [**Password stage**](../../stages/password/index.md)
+-   [**Authenticator Validation Stage**](../../stages/authenticator_validate/index.md)

website/docs/flow/executors/if-flow.md → website/docs/add-secure-apps/flows-stages/flow/executors/if-flow.md

@@ -5,5 +5,5 @@ title: Default
 This is the default, web-based environment that flows are executed in. All stages are compatible with this environment and no limitations are imposed.
 
 :::info
-All flow executors use the same [API](../../../developer-docs/api/flow-executor), which allows for the implementation of custom flow executors.
+All flow executors use the same [API](../../../../../developer-docs/api/flow-executor.md), which allows for the implementation of custom flow executors.
 :::

website/docs/flow/executors/sfe.md → website/docs/add-secure-apps/flows-stages/flow/executors/sfe.md

@@ -13,14 +13,14 @@ Currently this flow executor is automatically used for the following browsers:
 
 The following stages are supported:
 
--   [**Identification stage**](../stages/identification/)
+-   [**Identification stage**](../../stages/identification/index.md)
 
     :::info
     Only user identifier and user identifier + password stage configurations are supported; sources and passwordless configurations are not supported.
     :::
 
--   [**Password stage**](../stages/password/)
--   [**Authenticator Validation Stage**](../stages/authenticator_validate/)
+-   [**Password stage**](../../stages/password/index.md)
+-   [**Authenticator Validation Stage**](../../stages/authenticator_validate/index.md)
 
 Compared to the [default flow executor](./if-flow.md), this flow executor does _not_ support the following features:
 

website/docs/flow/executors/user-settings.md → website/docs/add-secure-apps/flows-stages/flow/executors/user-settings.md

@@ -10,4 +10,4 @@ The user interface (/if/user/) uses a specialized flow executor to allow individ
 
 Because the stages in a flow can change during its execution, be awre that configuring this executor to use any stage type other than Prompt or User Write will automatically trigger a redirect to the standard executor.
 
-An admin can customize which fields can be changed by the user by updating the default-user-settings-flow, or copying it to create a new flow with a Prompt Stage and a User Write Stage. Different variants of your flow can be applied to different [Brands](../../core/brands.md) on the same authentik instance.
+An admin can customize which fields can be changed by the user by updating the default-user-settings-flow, or copying it to create a new flow with a Prompt Stage and a User Write Stage. Different variants of your flow can be applied to different [Brands](../../../../customize/brands.md) on the same authentik instance.

website/docs/flow/index.md → website/docs/add-secure-apps/flows-stages/flow/index.md

@@ -2,7 +2,7 @@
 title: Flows
 ---
 
-Flows are a major component in authentik. In conjunction with stages and [policies](../policies/index.md), flows are at the heart of our system of building blocks, used to define and execute the workflows of authentication, authorization, enrollment, and user settings.
+Flows are a major component in authentik. In conjunction with stages and [policies](../../../customize/policies/index.md), flows are at the heart of our system of building blocks, used to define and execute the workflows of authentication, authorization, enrollment, and user settings.
 
 There are over a dozen default, out-of-the box flows available in authentik. Users can decide if they already have everything they need with the default flows or if they want to [create](#create-a-custom-flow) their own custom flow, using the Admin interface.
 
@@ -20,13 +20,13 @@ When these stages are successfully completed, authentik logs in the user.
 
 By default, policies are evaluated dynamically, right before the stage (to which a policy is bound) is presented to the user. This flexibility allows the login process to continue, change, or stop, based on the success or failure of each policy.
 
-This default behaviour can be altered by enabling the **Evaluate when flow is planned** option on the stage binding. With this setting a _flow plan_ containing all stages is generated upon flow execution. This means that all attached policies are evaluated upon execution. For more information about flow plans, read our [flow context documentation](../flow/context/index.md).
+This default behaviour can be altered by enabling the **Evaluate when flow is planned** option on the stage binding. With this setting a _flow plan_ containing all stages is generated upon flow execution. This means that all attached policies are evaluated upon execution. For more information about flow plans, read our [flow context documentation](./context/index.md).
 
-To determine which flow should be used, authentik will first check which default authentication flow is configured in the active [**Brand**](../core/brands.md). If no default is configured there, the policies in all flows with the matching designation are checked, and the first flow with matching policies sorted by `slug` will be used.
+To determine which flow should be used, authentik will first check which default authentication flow is configured in the active [**Brand**](../../../customize/brands.md). If no default is configured there, the policies in all flows with the matching designation are checked, and the first flow with matching policies sorted by `slug` will be used.
 
 ## Permissions
 
-Flows can have [policies](../flow/stages/index.md) assigned to them. These policies determine if the current user is allowed to see and use this flow.
+Flows can have [policies](../stages/index.md) assigned to them. These policies determine if the current user is allowed to see and use this flow.
 
 Keep in mind that in certain circumstances, policies cannot match against users and groups as there is no authenticated user yet.
 
@@ -46,9 +46,9 @@ To create a flow, follow these steps:
 2. In the Admin interface, navigate to **Flows and Stages -> Flows**.
 3. Click **Create**, define the flow using the [configuration settings](#flow-configuration-options) described below, and then click **Finish**.
 
-After creating the flow, you can then [bind specific stages](../flow/stages/index.md#bind-a-stage-to-a-flow) to the flow and [bind policies](../policies/working_with_policies/working_with_policies.md) to the flow to further customize the user's log in and authentication process.
+After creating the flow, you can then [bind specific stages](../stages/index.md#bind-a-stage-to-a-flow) to the flow and [bind policies](../../../customize/policies/working_with_policies/working_with_policies.md) to the flow to further customize the user's log in and authentication process.
 
-To determine which flow should be used, authentik will first check which default authentication flow is configured in the active [**Brand**](../core/brands.md). If no default is configured there, the policies in all flows with the matching designation are checked, and the first flow with matching policies sorted by `slug` will be used.
+To determine which flow should be used, authentik will first check which default authentication flow is configured in the active [**Brand**](../../../customize/brands.md). If no default is configured there, the policies in all flows with the matching designation are checked, and the first flow with matching policies sorted by `slug` will be used.
 
 ## Flow configuration options
 
@@ -64,17 +64,17 @@ When creating or editing a flow in the UI of the Admin interface, you can set th
 
 **Designation**: Flows are designated for a single purpose. This designation changes when a flow is used. The following designations are available:
 
--   **Authentication**: this option designates a flow to be used for authentication. The authentication flow should always contain a [**User Login**](stages/user_login/index.md) stage, which attaches the staged user to the current session.
+-   **Authentication**: this option designates a flow to be used for authentication. The authentication flow should always contain a [**User Login**](../stages/user_login/index.md) stage, which attaches the staged user to the current session.
 
 -   **Authorization**: designates a flow to be used for authorization. The authorization flow `default-provider-authorization-explicit-consent` should always contain a consent stage.
 
--   **Invalidation**: designates a flow to be used to invalidate a session. This flow should always contain a [**User Logout**](stages/user_logout.md) stage, which resets the current session.
+-   **Invalidation**: designates a flow to be used to invalidate a session. This flow should always contain a [**User Logout**](../stages/user_logout.md) stage, which resets the current session.
 
--   **Enrollment**: designates a flow for enrollment. This flow can contain any amount of verification stages, such as [**email**](stages/email/) or [**captcha**](stages/captcha/). At the end, to create the user, you can use the [**user_write**](stages/user_write.md) stage, which either updates the currently staged user, or if none exists, creates a new one.
+-   **Enrollment**: designates a flow for enrollment. This flow can contain any amount of verification stages, such as [**email**](../stages/email/index.mdx) or [**captcha**](../stages/captcha/index.md). At the end, to create the user, you can use the [**user_write**](../stages/user_write.md) stage, which either updates the currently staged user, or if none exists, creates a new one.
 
--   **Unenrollment**: designates a flow for unenrollment. This flow can contain any amount of verification stages, such as [**email**](stages/email/) or [**captcha**](stages/captcha/). As a final stage, to delete the account, use the [**user_delete**](stages/user_delete.md) stage.
+-   **Unenrollment**: designates a flow for unenrollment. This flow can contain any amount of verification stages, such as [**email**](../stages/email/index.mdx) or [**captcha**](../stages/captcha/index.md). As a final stage, to delete the account, use the [**user_delete**](../stages/user_delete.md) stage.
 
--   **Recovery**: designates a flow for recovery. This flow normally contains an [**identification**](stages/identification/) stage to find the user. It can also contain any amount of verification stages, such as [**email**](stages/email/) or [**captcha**](stages/captcha/). Afterwards, use the [**prompt**](stages/prompt/) stage to ask the user for a new password and the [**user_write**](stages/user_write.md) stage to update the password.
+-   **Recovery**: designates a flow for recovery. This flow normally contains an [**identification**](../stages/identification/index.md) stage to find the user. It can also contain any amount of verification stages, such as [**email**](../stages/email/index.mdx) or [**captcha**](../stages/captcha/index.md). Afterwards, use the [**prompt**](../stages/prompt/index.md) stage to ask the user for a new password and the [**user_write**](../stages/user_write.md) stage to update the password.
 
 -   **Stage configuration**: designates a flow for general setup. This designation doesn't have any constraints in what you can do. For example, by default this designation is used to configure Factors, like change a password and setup TOTP.