checking-member-access

Checking member access

Use this skill to answer "what can this person do here?" from the access control tools. The tools return the enforced level and where it comes from. This skill is for reading them correctly.

When to use this skill

• "What can this member do in this project?" / "Can this member edit feature flags?"
• "Who can edit dashboards?" / "Who has no access to experiments?"
• "Why can't this member open this dashboard?" / "Which tables is this role restricted from?"
• "Which properties are hidden from the support role?"
• "What does the analyst role grant?" / "What is the default access in this project?"

Not for changing rules. The read tools cannot write, and the settings page is where rules are edited.

Plan availability

• Free and pay-as-you-go plans have no access control, and the access control tools are not offered to them. If the tools are missing from the catalog, say that the plan does not include access control and suggest upgrading to the Boost plan. Link the plan comparison: https://posthog.com/platform-packages.
• Boost and Scale include the default levels and rules for single members on the project, on tools, on objects and on properties.
• Roles exist on every plan, but role rules are an Enterprise feature: they can be set and are enforced only there, and the three role access tools are offered only there. If the tools are missing, say that role-based access control needs the Enterprise plan, with the same link. On other plans a member's roles never change the enforced level.
• The tools do not say which plan the organization is on. A source_subject of role anywhere in a members-list result proves that role rules are enforced. Without that, ask the user whether the organization is on Enterprise before walking roles in step 4 of the workflow.

How access resolves

• Scopes. The project itself, then each tool (dashboard, insight, feature_flag, notebook, experiment, warehouse_objects, and so on), then single objects inside a tool, then person and event properties. The tool names are the keys of resources in a members-list entry.
• Project levels. member can view and edit the resources their other rules permit. admin can also edit project settings, manage the project's access rules, and delete the project.
• Tool and object levels. none cannot view. viewer can view but not change. editor can view and change. manager can also manage the access rules of the tool or object. Order: none < viewer < editor < manager.
• Property levels. none hides the property. read shows it. read_write also allows edits. Every property is read_write unless a rule exists.
• Bounds. minimum and maximum per tool, on defaults-get, are the levels a rule can set. A tool with minimum viewer can never be set to none.
• Subjects. A rule belongs to one member, one role, or everyone in the project (the default).
• Organization admins and owners have full access to everything in every project. No rule applies to them. organization_level is a number: 1 member, 8 admin, 15 owner.
• Creators have full access to the objects they created, and only those. A member with viewer on dashboards can still edit the dashboard they created, and cannot edit the others.
• Two resolution modes. Organizations resolve rules either most-specific-first (member rule, then role rules, then default, and object rule before tool rule) or legacy (the highest of the member's own rule and role rules wins). The tools do not say which mode applies. The server already applied it. So trust effective_access_level and never recompute it from the stored rules. If the user asks why, explain from inherited_access, not from your own precedence.