mirror of
https://github.com/zitadel/zitadel.git
synced 2025-10-16 08:40:44 +00:00
fix: replace Instance Settings with Default Settings in i18n and docs (#8143)
# Which Problems Are Solved - The console shows the Instance Settings title and a description. Instance settings should be replaced with Default settings # How the Problems Are Solved - The DESCRIPTIONS.SETTINGS.INSTANCE.TITLE and DESCRIPTIONS.SETTINGS.INSTANCE.DESCRIPTION have been replaced with Default Settings and in the corresponding translation files. Here's a screenshot:  # Additional Changes - The docs have been updated to replace remaining texts mentioning Instance Settings with Default Settings - Two unused texts have been deleted from the translation files - VSCode with Prettier have applied some markdown changes # Additional Context - Closes #7632 --------- Co-authored-by: Fabi <fabienne@zitadel.com>
This commit is contained in:
@@ -2,34 +2,35 @@
|
||||
title: APIs V3 (Preview)
|
||||
---
|
||||
|
||||
import DocCardList from '@theme/DocCardList';
|
||||
import CodeBlock from '@theme/CodeBlock';
|
||||
import ActionServiceProto from '!!raw-loader!./_v3_action_service.proto'
|
||||
import ActionExecutionProto from '!!raw-loader!./_v3_action_execution.proto'
|
||||
import ActionTargetProto from '!!raw-loader!./_v3_action_target.proto'
|
||||
import ActionSearchProto from '!!raw-loader!./_v3_action_search.proto'
|
||||
import IDPServiceProto from '!!raw-loader!./_v3_idp_service.proto'
|
||||
import IDPProto from '!!raw-loader!./_v3_idp.proto'
|
||||
import IDPSearchProto from '!!raw-loader!./_v3_idp_search.proto'
|
||||
import IDPGitLabProto from '!!raw-loader!./_v3_idp_gitlab.proto'
|
||||
import LanguageServiceProto from '!!raw-loader!./_v3_language_service.proto'
|
||||
import LanguageProto from '!!raw-loader!./_v3_language.proto'
|
||||
import ObjectProto from '!!raw-loader!./_v3_object.proto'
|
||||
import ResourceObjectProto from '!!raw-loader!./_v3_resource_object.proto'
|
||||
import SettingsObjectProto from '!!raw-loader!./_v3_settings_object.proto'
|
||||
import DocCardList from "@theme/DocCardList";
|
||||
import CodeBlock from "@theme/CodeBlock";
|
||||
import ActionServiceProto from "!!raw-loader!./_v3_action_service.proto";
|
||||
import ActionExecutionProto from "!!raw-loader!./_v3_action_execution.proto";
|
||||
import ActionTargetProto from "!!raw-loader!./_v3_action_target.proto";
|
||||
import ActionSearchProto from "!!raw-loader!./_v3_action_search.proto";
|
||||
import IDPServiceProto from "!!raw-loader!./_v3_idp_service.proto";
|
||||
import IDPProto from "!!raw-loader!./_v3_idp.proto";
|
||||
import IDPSearchProto from "!!raw-loader!./_v3_idp_search.proto";
|
||||
import IDPGitLabProto from "!!raw-loader!./_v3_idp_gitlab.proto";
|
||||
import LanguageServiceProto from "!!raw-loader!./_v3_language_service.proto";
|
||||
import LanguageProto from "!!raw-loader!./_v3_language.proto";
|
||||
import ObjectProto from "!!raw-loader!./_v3_object.proto";
|
||||
import ResourceObjectProto from "!!raw-loader!./_v3_resource_object.proto";
|
||||
import SettingsObjectProto from "!!raw-loader!./_v3_settings_object.proto";
|
||||
|
||||
The APIs described in this section are currently either in *Preview* stage or not implemented, yet.
|
||||
The APIs described in this section are currently either in _Preview_ stage or not implemented, yet.
|
||||
Before using these APIs, pleases consider the [API release policy below](#api-release-policy)
|
||||
|
||||
## We Appreciate your Help
|
||||
|
||||
We invite you to...
|
||||
|
||||
- ... [discuss the concept with the ZITADEL community on GitHub](https://github.com/zitadel/zitadel/discussions/8125).
|
||||
- ... try the implementations and provide feedback [by filing issues on GitHub](https://github.com/zitadel/zitadel/issues/new/choose).
|
||||
|
||||
## The Ideas behind the New V3 APIs
|
||||
|
||||
The current ZITADEL *GA* APIs are structured around contexts like System, Admin, Management, and Auth.
|
||||
The current ZITADEL _GA_ APIs are structured around contexts like System, Admin, Management, and Auth.
|
||||
This structure leads to duplicate methods and makes it hard to find the right API for the right task.
|
||||
Especially interacting with resources from multiple organizations is cumbersome.
|
||||
Also, the APIs evolved over time, which lead to inconsistencies and a lack of flexibility in development.
|
||||
@@ -53,7 +54,7 @@ Also, it allows for faster development and independent versioning of the APIs.
|
||||
|
||||
To improve managing and reusing resources and settings in multitenancy scenarios, we define some rules for the new APIs:
|
||||
|
||||
- Single properties from instance settings are overridable (patchable) in organizations.
|
||||
- Single properties from default settings are overridable (patchable) in organizations.
|
||||
- Some settings support user-defined custom properties that are also overridable in organizations.
|
||||
- Improved experience with reusing resources in multiple organizations and instances.
|
||||
- Resources are searchable over all organizations with a single call by default.
|
||||
@@ -61,6 +62,7 @@ To improve managing and reusing resources and settings in multitenancy scenarios
|
||||
### HTTP and gRPC Consistency
|
||||
|
||||
To make the APIs more consistent and easier to use, we follow the same patterns in all Proto files.
|
||||
|
||||
- Patching is favored over updating resources and settings.
|
||||
- HTTP calls are mapped so that query parameters can be used as much as possible. We avoid the annotation `body: "*"`.
|
||||
- For search performance, we enforce query limits.
|
||||
@@ -93,20 +95,20 @@ Reusable resources have the same behavior as standard resources with the followi
|
||||
|
||||
- Reusable resources can be created in a given context level (system, instance, org).
|
||||
- For requests, that require a resource ID, no request context is needed.
|
||||
- Reusable resources are available in child contexts, even if their state is *inactive*.
|
||||
- Reusable resources are available in child contexts, even if their state is _inactive_.
|
||||
- The child context can control if an inherited resource should be active or inactive for itself using a state policy.
|
||||
- In child contexts, the state policy of a reused resource is *inherit* by default and can be changed to *activate*, *deactivate* or back to *inherit*.
|
||||
- In child contexts, the state policy of a reused resource is _inherit_ by default and can be changed to _activate_, _deactivate_ or back to _inherit_.
|
||||
- In child contexts, a reused resources configuration is read-only.
|
||||
- Child contexts can read at least the following properties of reused resources:
|
||||
- ID
|
||||
- name
|
||||
- description
|
||||
- state
|
||||
- the state policy in the child context
|
||||
- sequence
|
||||
- last changed date
|
||||
- parent context
|
||||
- state in the immediate parent context.
|
||||
- ID
|
||||
- name
|
||||
- description
|
||||
- state
|
||||
- the state policy in the child context
|
||||
- sequence
|
||||
- last changed date
|
||||
- parent context
|
||||
- state in the immediate parent context.
|
||||
- By default, search queries for reused resources return all resources from the given contexts, all inherited resources and all resources defined in all children contexts.
|
||||
|
||||
Typically, a new resource is first designed and implemented as a non-reusable resource.
|
||||
@@ -135,19 +137,19 @@ Additional to the standard CRUD methods:
|
||||
- ListAvailableExecutionFunctions
|
||||
|
||||
\<details><summary>action_service.proto</summary>
|
||||
<CodeBlock language="protobuf">{ActionServiceProto}</CodeBlock>
|
||||
<CodeBlock language="protobuf">{ActionServiceProto}</CodeBlock>
|
||||
\</details>
|
||||
|
||||
\<details><summary>action_target.proto</summary>
|
||||
<CodeBlock language="protobuf">{ActionTargetProto}</CodeBlock>
|
||||
<CodeBlock language="protobuf">{ActionTargetProto}</CodeBlock>
|
||||
\</details>
|
||||
|
||||
\<details><summary>action_execution.proto</summary>
|
||||
<CodeBlock language="protobuf">{ActionExecutionProto}</CodeBlock>
|
||||
<CodeBlock language="protobuf">{ActionExecutionProto}</CodeBlock>
|
||||
\</details>
|
||||
|
||||
\<details><summary>action_query.proto</summary>
|
||||
<CodeBlock language="protobuf">{ActionSearchProto}</CodeBlock>
|
||||
<CodeBlock language="protobuf">{ActionSearchProto}</CodeBlock>
|
||||
\</details>
|
||||
|
||||
### ZITADELUsers
|
||||
@@ -164,27 +166,27 @@ Standard CRUD methods
|
||||
- Resources have additional properties for reusability capabilities.
|
||||
|
||||
\<details><summary>idp_service.proto</summary>
|
||||
<CodeBlock language="protobuf">{IDPServiceProto}</CodeBlock>
|
||||
<CodeBlock language="protobuf">{IDPServiceProto}</CodeBlock>
|
||||
\</details>
|
||||
|
||||
\<details><summary>idp.proto</summary>
|
||||
<CodeBlock language="protobuf">{IDPProto}</CodeBlock>
|
||||
<CodeBlock language="protobuf">{IDPProto}</CodeBlock>
|
||||
\</details>
|
||||
|
||||
\<details><summary>idp_search.proto</summary>
|
||||
<CodeBlock language="protobuf">{IDPSearchProto}</CodeBlock>
|
||||
<CodeBlock language="protobuf">{IDPSearchProto}</CodeBlock>
|
||||
\</details>
|
||||
|
||||
\<details><summary>idp_gitlab.proto</summary>
|
||||
<CodeBlock language="protobuf">{IDPGitLabProto}</CodeBlock>
|
||||
<CodeBlock language="protobuf">{IDPGitLabProto}</CodeBlock>
|
||||
\</details>
|
||||
|
||||
\<details><summary>object.proto</summary>
|
||||
<CodeBlock language="protobuf">{ObjectProto}</CodeBlock>
|
||||
<CodeBlock language="protobuf">{ObjectProto}</CodeBlock>
|
||||
\</details>
|
||||
|
||||
\<details><summary>resource_object.proto</summary>
|
||||
<CodeBlock language="protobuf">{ResourceObjectProto}</CodeBlock>
|
||||
<CodeBlock language="protobuf">{ResourceObjectProto}</CodeBlock>
|
||||
\</details>
|
||||
|
||||
### ZITADELInstances
|
||||
@@ -252,7 +254,7 @@ These properties are inherited to from parent-contexts (instance) to child-conte
|
||||
|
||||
Settings behave like this:
|
||||
|
||||
- Setting and retrieving settings is always context-aware. By default, the context is the instance discovered by the requests *Host* header.
|
||||
- Setting and retrieving settings is always context-aware. By default, the context is the instance discovered by the requests _Host_ header.
|
||||
- All settings properties can be partially overridden in child-contexts.
|
||||
- All settings properties can be partially reset in child-contexts, so their values default to the parent contexts property values.
|
||||
- All settings properties returned by queries contain the value and if it is inherited, the context where it is inherited from.
|
||||
@@ -266,19 +268,19 @@ For a full proto example, have a look at the [ZITADELLanguageSettings service](#
|
||||
Default language, restricted languages, supported languages
|
||||
|
||||
\<details><summary>language_service.proto</summary>
|
||||
<CodeBlock language="protobuf">{LanguageServiceProto}</CodeBlock>
|
||||
<CodeBlock language="protobuf">{LanguageServiceProto}</CodeBlock>
|
||||
\</details>
|
||||
|
||||
\<details><summary>language.proto</summary>
|
||||
<CodeBlock language="protobuf">{LanguageProto}</CodeBlock>
|
||||
<CodeBlock language="protobuf">{LanguageProto}</CodeBlock>
|
||||
\</details>
|
||||
|
||||
\<details><summary>object.proto</summary>
|
||||
<CodeBlock language="protobuf">{ObjectProto}</CodeBlock>
|
||||
<CodeBlock language="protobuf">{ObjectProto}</CodeBlock>
|
||||
\</details>
|
||||
|
||||
\<details><summary>settings_object.proto</summary>
|
||||
<CodeBlock language="protobuf">{SettingsObjectProto}</CodeBlock>
|
||||
<CodeBlock language="protobuf">{SettingsObjectProto}</CodeBlock>
|
||||
\</details>
|
||||
|
||||
### ZITADELTextSettings
|
||||
@@ -326,9 +328,9 @@ Replaces secret generators
|
||||
## API Release Policy
|
||||
|
||||
- Defined but not yet implemented APIs are subject to change without further notice.
|
||||
- Once an API definition is implemented, it is released as *Preview* and is available for testing.
|
||||
- When a *Preview* API is tested enough so the concepts are proven to work, a new *Beta* API is released.
|
||||
- When an API is feature-complete and stable enough, a new *GA* (General Availability) API is released.
|
||||
- Once an API definition is implemented, it is released as _Preview_ and is available for testing.
|
||||
- When a _Preview_ API is tested enough so the concepts are proven to work, a new _Beta_ API is released.
|
||||
- When an API is feature-complete and stable enough, a new _GA_ (General Availability) API is released.
|
||||
- In all stages, changes to already implemented APIs are done in a backwards-compatible way, if possible.
|
||||
- When we release a new stage for an API, we deprecate the previous stage and keep it available for a smooth transition.
|
||||
|
||||
@@ -337,4 +339,4 @@ Replaces secret generators
|
||||
These APIs are ready for testing and feedback.
|
||||
Beware, they don't yet follow all the rules defined above.
|
||||
|
||||
<DocCardList />
|
||||
<DocCardList />
|
||||
|
Reference in New Issue
Block a user