Help us learn about your current experience with the documentation. Take the survey.

预定义的用户角色系统

实例

每个用户可以是以下类型之一：

有关每种用户类型如何使用的详细信息，请参阅权限页面。

群组和项目可以具有以下可见性级别：

默认情况下，子群组不能具有更高的可见性级别。例如，如果您创建一个新的私有群组，它不能包含公开的子群组。

仅当所有子群组和子项目具有相同或更低的可见性级别时，才能更改群组的可见性级别。例如，仅当所有子群组和项目都是内部或私有时，群组才能设置为内部。

如果您将现有群组迁移到更低的可见性级别，该操作不会以相同方式迁移子群组。这是一个已知问题。

可见性级别可以在 Gitlab::VisibilityLevel 模块中找到。

此外，以下项目功能可以具有不同的可见性级别：

这些功能可以设置为"所有有权限的用户"或"仅项目成员"。它们仅适用于公开或内部项目，因为私有项目默认只能由项目成员访问。

用户可以是多个群组和项目的成员。提供以下访问级别（在 Gitlab::Access 模块中定义）：

如果用户同时是项目和项目父群组的成员，则应用的访问级别是最高权限。

如果用户是项目的成员，但不是父群组的成员，他们仍然可以查看群组及其实体（如史诗）。

项目成员资格（已考虑群组成员资格）存储在 project_authorizations 表中。

个人命名空间中的项目最高角色为所有者。

在 GitLab 中具有访客角色的用户可以查看项目计划、障碍和其他进度指标。虽然无法修改未创建的数据，但访客可以通过创建和链接项目工作项来为项目做出贡献。访客还可以查看高级项目信息，例如：

有关更多信息，请参阅项目成员权限。

机密问题只能由至少是报告者的项目成员访问（访客无法访问）。此外，它们的作者和被分配者也可以访问。

某些功能只有在用户拥有正确的许可证计划时才能访问。

功能策略可能相当复杂，包含多个规则。通常，一个权限可能基于另一个权限。

设计良好的权限意味着尽可能重用现有权限，并使功能访问具有粒度性。

对于复杂资源，应将其分解为更小的信息片段，并为每个片段授予不同的权限。

这方面的一个很好的例子是_合并请求小部件_和_安全报告_。根据_流水线_的可见性级别，_安全报告_要么在小部件中可见，要么不可见。因此，合并请求小部件、_流水线_和_安全报告_具有独立的权限。此外，_合并请求小部件_和_流水线_的权限是_安全报告_的依赖项。

安全功能具有复杂的权限，因为这些功能集成了到合并请求和 CI 流等不同功能中。

以下是一些权限依赖的列表。