Checking Member Access

Workflow

1. Find the subject id. member_id is the organization membership id: the id from org-members-list, or organization_membership_id from members-list. It is not the user id and not the user uuid. role_id is the id from roles-list.
2. Tool-level questions need one call. "Can this member view dashboards?" or "What access to feature flags does this member have?" is members-list with member_id. effective_access_level for that tool is the complete answer. It already includes the member's roles, the project default and the bypasses.
3. Explain the level from inherited_access. See the table below. Only mention the stored access_level when it differs from the enforced level.
4. Object questions need the object and its rules. "Can this member open dashboard 42?" cannot be answered from the tool level alone. Check in this order, and stop at the first hit:
   1. organization_level is 8 or 15 on the member's entry: full access, no rule applies.
   2. The member created the object: full access, no rule applies. The rule tools do not say who created an object, so fetch it with its own get tool, for example dashboard-get or insight-get, and compare created_by.uuid with user.uuid on the member's entry.
   3. A rule on that object. The member tools return only the rules set for that member, so collect member-objects-list, role-objects-list for each id in the member's role_ids, and default-objects-list, and pick out the rows for this object. Tell the user how many roles you would walk and ask before doing it for a member in many roles.
   4. No rule on the object: the tool-level answer from step 2 applies.
5. Several rules on one object. When the member, a role and the default each set a level on the same object, the server picks one by the organization's resolution mode, and no tool returns that pick for another member. Report every rule you found with its subject, say the enforced one depends on the mode, and do not guess. Property questions work like step 4 with the properties tools, minus the creator check, since properties have no creator.
6. "Who can ..." questions are members-list without member_id, filtered on resources.<tool>.effective_access_level. The response is every member times every tool and has no pagination. For a large organization, ask which people the user cares about first, or answer per member.

Reading one entry

How to phrase the answer:

• source is org_admin: "This member is an organization admin and has full access to everything." The stored rules do not apply to them.
• access_level is set and equals effective_access_level: "This member has an explicit rule: editor."
• access_level is null and source_subject is role: "This member has editor access, based on a role." The role's name is not in the entry; roles-list has it if the user wants it.
• access_level is null and source_subject is default: "This member has viewer access, based on the project default."
• source is system_default: "No rule is set anywhere, so the PostHog default applies."
• effective_access_level is null: "Nothing resolves for this tool here." Do not read it as no access.

Gotchas

• An empty object or property list means no rules of that kind, not no access. The tool-level entry still applies.
• A member missing from members-list is not proof of no access. A caller who is not an organization admin, in an organization where members cannot see each other, only sees members with project-scoped access.
• can_edit on the members and roles lists describes the caller, not the subject: whether the person running the tool may change rules.
• available_project_levels and available_resource_levels are the vocabulary, lowest first. Use them to compare levels instead of assuming an order.
• object_rule_resources on defaults-get lists the tools that accept rules on single objects. A tool not in that list has no object rules to look for.