Users & Groups

Honeyframe's access control model has two independent axes:

• Seat types govern licensing — every user has exactly one of admin, builder, analyst, or viewer. Seat types determine which areas of the product a user can reach at all (e.g. analysts can build dashboards but not edit ingestion flows).
• Group permissions govern security — what specific objects a user can read, edit, or administer. Groups are orthogonal to seat types: a viewer in the "Finance Leadership" group may have read access to dashboards a builder in the "Marketing" group cannot see.

Groups themselves can be local (managed inside Honeyframe) or LDAP-mapped (synced from a directory server via the group's ldap_dn). LDAP-mapped groups carry the same permission grants as local groups; the only difference is membership source.

Permissions attach to groups via permission_type strings (for example dashboard.edit, dataset.read, org.admin) and may optionally be scoped to a specific object using target_id. The platform resolves a permission check by first granting the request if the user is a superadmin, then falling back to a legacy single-role check for backwards compatibility, and finally consulting the user's group memberships and the permissions attached to those groups. Frontend code uses the usePermission() hook and the <ProtectedRoute> component to gate UI surfaces declaratively.

The /api/groups endpoints provide CRUD for groups and their permission grants. The frontend bootstraps its permission cache from /api/groups/me/permissions on login.