Understanding permissions and roles in the UI

TL;DR

• I wanted to understand how permissions and roles control UI elements, since I saw userPermissions fetched via GraphQL but not much frontend permission checking
• Context came from building a scenario table to test whether users should see source projects of private agents/flows, which multiplied into many role/access combinations
• Agent 3771 explained permissions are enforced on the backend via the declarative policy framework, with thorough unit tests (often using shared_examples and parameterized tests) covering the full matrix of role scenarios
• Frontend stays minimally aware of permissions, just exposing booleans through GraphQL so it can decide what UI to show, while the backend remains the gatekeeper
• Takeaway: when facing permission questions while building UI, confirm needed scopes with the team, check if a relevant permission boolean already exists, or ask for one to be created

Slack thread on permissions

I asked about wanting to more deeply understand how permissions and roles control UI elements. I noticed userPermissions being fetched on various GraphQL queries but not much permission checking happening in the frontend, which suggested a lot is handled on the backend or through other abstracted mechanisms. My context: I was building a table of scenarios to test whether a user should see source projects of agents/flows that were private, and quickly realized there were many combinations of roles (external, internal, minimal, planner, reporter, etc.), invitation types, and screens (Explore > AI Catalog, Automate > Project, Automate > Group) to consider. I asked how to effectively think through these scenarios in general development and how to write effective tests for them.

Agent 3771 explained that permissions are enforced on the backend using the declarative policy framework, and are tested very thoroughly with a unit test for each policy — for example, ItemPolicy for AI Catalog Items has a corresponding spec testing every role type from owner through anonymous, against both private and public items. They test effectively using shared_examples to DRY up tests and parameterized tests to iterate through scenarios, aiming to cover the full matrix of possibilities. The frontend should only be minimally aware of permissions — GraphQL exposes booleans so the frontend can work out what to show, but the backend is always the gatekeeper.

I thanked Agent 3771 and confirmed my understanding: when I hit a potential rabbit hole of permission considerations while building a UI element, I can confirm what permission scopes are needed with the team, check if a permission is already being returned on the data element, or ask for one to be created. Agent 3771 confirmed this was right, adding that for GraphQL, booleans of permissions are exposed on objects, and for frontend work using Rails views, permission checks are likely made within a Rails helper and used in the frontend work.