checking-member-access

检查成员访问权限

使用此技能，通过访问控制工具回答“这个人可以在这里做什么？”。这些工具会返回实际生效的级别及其来源。本技能旨在帮助你正确解读这些信息。

何时使用此技能

• “这位成员在此项目中可以做什么？”／“这位成员可以编辑功能标志吗？”
• “谁可以编辑仪表板？”／“谁无权访问实验？”
• “为什么这位成员打不开这个仪表板？”／“此角色受到限制，无法访问哪些表？”
• “哪些属性对支持角色不可见？”
• “analyst 角色授予了什么权限？”／“此项目中的默认访问权限是什么？”

也可以使用 MCP 写入工具更改访问规则。先读取当前规则并说明变更，然后使用 prepare/execute 流程；只有在用户确认后才能调用 execute。

计划可用性

• Free 和 pay-as-you-go 计划不提供访问控制，也不会向其用户提供访问控制工具。如果工具目录中没有这些工具，请说明该计划不包含访问控制，并建议升级到 Boost 计划。计划对比链接：https://posthog.com/platform-packages。
• Boost 和 Scale 包含针对项目、工具、对象和属性的默认级别及规则，这些规则适用于单个成员。
• 所有计划都支持角色，但角色规则是 Enterprise 功能：只能在 Enterprise 计划中设置并生效，且只有 Enterprise 计划会提供三个角色访问工具。如果缺少这些工具，请说明基于角色的访问控制需要 Enterprise 计划，并提供相同的链接。在其他计划中，成员的角色不会改变实际生效的级别。
• 工具不会说明组织使用的是哪个计划。members-list 结果中任何位置出现 source_subject 为 role，即可证明角色规则正在生效。否则，在工作流第 4 步检查角色之前，请询问用户组织是否使用 Enterprise 计划。

访问权限如何解析

• 范围。 先是项目本身，然后是每种工具（dashboard、insight、feature_flag、notebook、experiment、warehouse_objects 等），接着是工具中的单个对象，最后是人员属性和事件属性。工具名称是 members-list 条目中 resources 的键。
• 项目级别。 none 会阻止访问项目及其资源。member 可以查看和编辑其他规则允许其访问的资源。admin 还可以编辑项目设置、管理项目的访问规则并删除项目。
• 工具和对象级别。 none 表示无法查看。viewer 可以查看但不能更改。editor 可以查看和更改。manager 还可以管理该工具或对象的访问规则。级别顺序：none < viewer < editor < manager。
• 属性级别。 none 会隐藏属性。read 会显示属性。read_write 还允许编辑。除非存在规则，否则每个属性的级别都是 read_write。
• 级别范围。 defaults-get 中每种工具的 minimum 和 maximum 表示规则可设置的级别。如果工具的 minimum 是 viewer，则绝不能将其设置为 none。
• 主体。 一条规则适用于某个成员、某个角色，或项目中的所有人（默认值）。
• 组织管理员和所有者在每个项目中都拥有所有内容的完整访问权限。规则不适用于他们。organization_level 是一个数字：1 表示成员，8 表示管理员，15 表示所有者。
• 创建者对自己创建的对象拥有完整访问权限，仅限这些对象。拥有仪表板 viewer 权限的成员仍可编辑自己创建的仪表板，但不能编辑其他仪表板。
• 两种解析模式。 组织可以采用最具体规则优先的模式（依次为成员规则、角色规则、默认规则；对象规则优先于工具规则），也可以采用旧版模式（成员自身规则与角色规则中，取级别较高者）。工具不会说明适用哪种模式；服务端已经完成解析。因此，请信任 effective_access_level，绝不要根据已存储的规则重新计算。 如果用户询问原因，请依据 inherited_access 进行说明，不要自行推断优先级。

可用工具

工具	返回内容
posthog:access-control-members-list	每位成员对项目及每个工具的强制访问权限。member_id 可限定到某位成员。
posthog:access-control-roles-list	按角色返回相同信息。role_id 可限定到某个角色。
posthog:access-control-defaults-get	项目基线，以及哪些工具接受针对单个对象的规则。
posthog:access-control-default-rule-set-prepare / posthog:access-control-default-rule-set-execute	为某个范围设置或清除默认规则。
posthog:access-control-member-rule-set-prepare / posthog:access-control-member-rule-set-execute	为某个范围设置或清除单个成员的规则。
posthog:access-control-role-rule-set-prepare / posthog:access-control-role-rule-set-execute	为某个范围设置或清除单个角色的规则。
posthog:access-control-member-objects-list	为成员设置的对象规则：每个为该成员设置了规则的对象。
posthog:access-control-member-properties-list	为成员设置的属性规则。
posthog:access-control-role-objects-list	为角色设置的对象规则。
posthog:access-control-role-properties-list	为角色设置的属性规则。
posthog:access-control-default-objects-list	适用于项目中所有人的对象规则。
posthog:access-control-default-properties-list	适用于项目中所有人的属性规则。
posthog:org-members-list	成员资格 ID、姓名和组织级别。不包含项目访问详情。
posthog:roles-list、posthog:role-members-list	按 ID 列出角色名称，以及角色成员。

所有访问控制工具都接受可选的项目 ID，默认使用当前活跃项目。

工作流

1. 查找主体 ID。 member_id 是组织成员资格 ID：来自 org-members-list 的 id，或来自 members-list 的 organization_membership_id。它不是用户 ID，也不是用户 UUID。role_id 是来自 roles-list 的 id。
2. 工具级问题只需调用一次。“该成员能查看仪表板吗？”或“该成员对功能标志有什么访问权限？”应调用带 member_id 的 members-list。该工具返回的 effective_access_level 就是完整答案。它已包含该成员的角色、项目默认值和绕过规则。
3. **根据 inherited_access 解释级别。**请参阅下表。只有当存储的 access_level 与实际执行的级别不同时，才提及它。
4. 对象问题需要检查对象及其规则。“该成员能打开仪表板 42 吗？”不能仅凭工具级别回答。按以下顺序检查，命中第一项后即停止：
   1. 成员条目中的 organization_level 为 8 或 15：完全访问，不适用任何规则。
   2. 成员创建了该对象：完全访问，不适用任何规则。规则工具不会指出对象的创建者，因此请使用对象自己的 get 工具获取对象，例如 dashboard-get 或 insight-get，并将 created_by.uuid 与成员条目中的 user.uuid 比较。
   3. 对象上的规则。成员工具只会返回为该成员设置的规则，因此请收集 member-objects-list、该成员 role_ids 中每个 ID 对应的 role-objects-list，以及 default-objects-list，并筛选出此对象对应的行。告诉用户需要遍历多少个角色；如果该成员有很多角色，请先询问是否继续。
   4. 对象上没有规则：适用步骤 2 中的工具级答案。
5. **同一对象上的多条规则。**如果成员、某个角色和默认设置分别为同一对象设定了级别，服务端会根据组织的解析模式选出一个级别；没有任何工具会返回针对其他成员的选定结果。请报告找到的每条规则及其主体，并说明实际执行的规则取决于解析模式，不要猜测。属性问题按步骤 4 处理，使用属性工具，但跳过创建者检查，因为属性没有创建者。
6. “谁可以……”问题应调用不带 member_id 的 members-list，并按 resources.<tool>.effective_access_level 筛选。响应包含每个成员与每个工具的组合，且没有分页。对于大型组织，请先询问用户关心哪些人，或按成员逐一回答。

阅读单条记录

字段	含义
access_level	主体为此范围存储的自身规则。null 表示主体没有自己的规则。
effective_access_level	实际生效的权限。null 表示此范围没有解析出任何权限。这不等于“无权访问”。
inherited_access	主体没有自身规则时回退使用的权限级别，以及该权限的来源。没有任何来源提供权限时为 null。
inherited_access.source	对于工具规则，值为 resource 或 parent_resource；对于对象规则，值为 object 或 parent_object；对于 PostHog 默认权限，值为 system_default。org_admin 和 creator 是上文所述的绕过情况。只有当对象本身是组织时，才会出现 org_membership。
inherited_access.source_subject	提供规则的主体：member、role 或 default。如果权限来自绕过情况或 PostHog 默认权限，则为 null。

回答时可以这样表述：

• source 为 org_admin：“此成员是组织管理员，可以完全访问所有内容。”存储的规则对其不适用。
• access_level 已设置且等于 effective_access_level：“此成员有一条明确规则：editor。”
• access_level 为 null 且 source_subject 为 role：“此成员基于角色拥有 editor 权限。”记录中没有角色名称；如果用户需要，可以通过 roles-list 查看。
• access_level 为 null 且 source_subject 为 default：“此成员基于项目默认设置拥有 viewer 权限。”
• source 为 system_default：“任何位置都没有设置规则，因此采用 PostHog 默认权限。”
• effective_access_level 为 null：“此工具在此处没有解析出任何权限。”不要将其理解为无权访问。

注意事项

• 空对象或属性列表表示没有该类规则，而非没有访问权限。工具级条目仍然适用。
• 项目默认权限设为 none 不会撤销成员或角色的明确授权。请检查成员和角色列表，查找这些授权。组织管理员和所有者始终可以绕过项目规则。
• members-list 中没有某个成员，并不能证明该成员没有权限。如果调用者不是组织管理员，且所在组织不允许成员查看彼此，那么调用者只能看到拥有项目级权限的成员。
• 成员和角色列表中的 can_edit 描述的是调用者，而非主体：也就是运行工具的人是否可以更改规则。
• available_project_levels 和 available_resource_levels 列出了可用的权限级别，顺序从最低到最高。请用它们比较权限级别，不要自行假设顺序。
• defaults-get 中的 object_rule_resources 列出了支持对单个对象设置规则的工具。不在该列表中的工具无需查找对象规则。