mirror of
https://github.com/andwati/zitadel.git
synced 2026-11-08 15:15:12 +00:00
chore: rename manager/member to administrator (#11542)
# Which Problems Are Solved As part of the naming consistency initiative, the terms `Manager`, `Member` and other similar terms that are used in the context of an administrator are replaced by `Administrator` in the UI and documentation. # How the Problems Are Solved By replacing the following terms with Administrator / Administrator Roles in docs, Console UI, and guides. - Manager - Add Manager - Add a Manager - Administrator (used as a person type) - Membership - Member grants # Additional Changes minor grammatical edits in the docs # Additional Context - Closes https://github.com/zitadel/zitadel/issues/11291 --------- Co-authored-by: Marco A. <[email protected]>
This commit is contained in:
co-authored by
Marco A.
parent
319c466476
commit
cc7a6145f1
@@ -11,7 +11,7 @@ Administrators can [restrict end-users from accessing the management console](/g
|
||||
|
||||
Here's an overview of what the management console enables users to do:
|
||||
|
||||
1. **Default Settings:** [Managers](/concepts/structure/managers) can access and manage the default settings of the ZITADEL system. This includes configuring authentication methods, security policies, and other system-wide parameters to meet the organization's requirements.
|
||||
1. **Default Settings:** [Administrators](/concepts/structure/administrators) can access and manage the default settings of the ZITADEL system. This includes configuring authentication methods, security policies, and other system-wide parameters to meet the organization's requirements.
|
||||
|
||||
2. **Resource Management:** The management console allows for the creation, updating, and deletion of essential resources such as organizations, users, projects, and applications. Administrators can efficiently manage these entities to ensure proper access control and governance.
|
||||
|
||||
@@ -23,7 +23,7 @@ Here's an overview of what the management console enables users to do:
|
||||
|
||||
6. **Customization and Branding:** The management console allows organizations to customize the branding and appearance of their ZITADEL instance. This includes uploading custom logos, selecting color schemes, and applying other visual customizations to align the interface with the organization's branding guidelines.
|
||||
|
||||
7. **Manager Assignment:** Administrators can assign ZITADEL [managers](/concepts/structure/managers) who have elevated privileges for managing resources within the organization. This allows for the delegation of administrative tasks while maintaining proper oversight and control.
|
||||
7. **Administrator Assignment:** Administrators can assign ZITADEL [administrators](/concepts/structure/administrators) who have elevated privileges for managing resources within the organization. This allows for the delegation of administrative tasks while maintaining proper oversight and control.
|
||||
|
||||
Overall, the ZITADEL management console serves as a comprehensive tool for administrators to configure, manage, and monitor identity and access management within their organization, providing the necessary controls to ensure security, compliance, and efficient administration of resources.
|
||||
|
||||
|
||||
@@ -57,7 +57,7 @@ For example some organizations might use their EntraID, some other want to login
|
||||
Using an identity provider with strong multitenancy capabilities such as ZITADEL, you can configure a different set of external identity providers per organization.
|
||||
|
||||
[Domain discovery](/guides/solution-scenarios/domain-discovery) ensures that users are redirected to their external identity provider based on their email-address or username.
|
||||
[Managers](../structure/managers) can configure organization domains that are used for domain-based redirection to an external IdP.
|
||||
[Administrators](../structure/administrators) can configure organization domains that are used for domain-based redirection to an external IdP.
|
||||
|
||||

|
||||
|
||||
|
||||
@@ -9,12 +9,12 @@ For these tasks we either provide a user interface, or the tasks can be initiate
|
||||
It is important to understand that, depending on your use case, there will exist different user-types that want to perform different actions:
|
||||
|
||||
- `Users` are the end-users of your application. Like with any CIAM solution, users should be able to perform tasks like register/join, update their profile, manage authenticators, etc. There are certain actions that can be executed pre-login, yet others require the user to have a valid session.
|
||||
- `Managers` are users with a [special administrator role](../../guides/manage/console/managers) within ZITADEL and can perform administrative actions such as system configuration or granting access rights to users.
|
||||
- `Administrators` are users with a [special administrator role](../../guides/manage/console/administrators) within ZITADEL and can perform administrative actions such as system configuration or granting access rights to users.
|
||||
|
||||
All self-service interfaces are available in different [languages](/guides/manage/customize/texts#internationalization-i-18-n).
|
||||
|
||||
<Callout>
|
||||
ZITADEL covers the typical "CIAM" self-service capabilities as well as delegated access management for multi-tenancy scenarios. Please refer to the section [Managers](#managers).
|
||||
ZITADEL covers the typical "CIAM" self-service capabilities as well as delegated access management for multi-tenancy scenarios. Please refer to the section [Administrators](#administrators).
|
||||
</Callout>
|
||||
|
||||
## Registration
|
||||
@@ -126,24 +126,24 @@ Users can create a connection between a [local user account](#local-account) and
|
||||
The user can log in with any of the linked accounts.
|
||||
[Linking of external accounts](#account-linking) is done during the login process.
|
||||
|
||||
## Managers
|
||||
## Administrators
|
||||
|
||||
It is important to note that a `Manager` is not simply an administrative user, but can be used to create much more advanced scenarios such as delegating administration of a whole organization to a user, acting then as administrator and permission manager of that user group.
|
||||
It is important to note that an `Administrator` is not simply an administrative user, but can be used to create much more advanced scenarios such as delegating administration of a whole organization to a user, acting then as administrator and permission manager of that user group.
|
||||
|
||||
Thus, we will explain service for two of the most common scenarios in ZITADEL:
|
||||
|
||||
- `Managers in isolation`: Granting administrative permissions within a single organization context.
|
||||
- `Managers in delegation`: Granting administrative permissions to a user from a different organization where the organizations depend on each other
|
||||
- `Administrators in isolation`: Granting administrative permissions within a single organization context.
|
||||
- `Administrators in delegation`: Granting administrative permissions to a user from a different organization where the organizations depend on each other
|
||||
|
||||
A list of [Administrator Roles](../../guides/manage/console/managers#roles) is available with a description of permissions.
|
||||
Managers can be assigned to both human users and service users, e.g., for managing certain tasks programmatically.
|
||||
A list of [Administrator Roles](../../guides/manage/console/administrators#roles) is available with a description of permissions.
|
||||
Administrators can be assigned to both human users and service users, e.g., for managing certain tasks programmatically.
|
||||
|
||||
### Managers in isolation
|
||||
### Administrators in isolation
|
||||
|
||||
A user with Administrator roles `IAM_OWNER` or `ORG_OWNER` might want to assign other users from their organization elevated permissions to handle certain aspects of the IAM tasks.
|
||||
This could be permission to assign authorizations within this isolated organization (`ORG_USER_MANAGER`) or handling setup of projects and applications (`PROJECT_OWNER`).
|
||||
|
||||
### Managers in delegation
|
||||
### Administrators in delegation
|
||||
|
||||
In a setup like described in the [B2B Scenario](/guides/solution-scenarios/b2b), there exists an organization of the project owner and a customer organization.
|
||||
The project is granted to the customer organization, such that the customer can access the project and assign authorization to their users.
|
||||
@@ -151,6 +151,6 @@ The project is granted to the customer organization, such that the customer can
|
||||
Given such as set up the owner might want to give one administrative user of the customer organization the role `ORG_OWNER`.
|
||||
Equipped with this Administrator Role, the user can perform actions like configuring their own SSO/Identity Provider, set security policy for their organization, customize branding, or assign project or Administrator roles to other users.
|
||||
|
||||
An `ORG_OWNER` can also not only delegate Administrator roles to other users [as described in the earlier section](#managers-in-isolation) but also manage all aspects of their own organization as well as authorize users to use the granted project.
|
||||
An `ORG_OWNER` can also not only delegate Administrator roles to other users [as described in the earlier section](#administrators-in-isolation) but also manage all aspects of their own organization as well as authorize users to use the granted project.
|
||||
With ZITADEL there is no need to replicate all settings and projects across organizations.
|
||||
Instead, you could set up the project in one organization, delegate it to different organizations, and then appoint users as Managers of that organization to allow for self-service in a multi-tenancy scenario.
|
||||
Instead, you could set up the project in one organization, delegate it to different organizations, and then appoint users as Administrators of that organization to allow for self-service in a multi-tenancy scenario.
|
||||
|
||||
Reference in New Issue
Block a user