**modelling separate view and admin

**modelling separate view and admin_view

Conviley

09/22/2025, 1:48 PM

modelling separate view and admin_view permissions Imagine you have a multi-tenant application where organisations can have multiple projects and a bunch of sharable resources with CRUD permissions under those projects. Organisation members work in projects but organisation admins can view all projects. To not bloat the project listing page for admins you want the option for them to toggle and only list those project which they have created, or directly/via group membership been made a

viewer

of. How would i model this schema?

Conviley

09/22/2025, 1:57 PM

The only alternative i've thought about how to solve this is creating a duplication of all CRUD permissions prefixed e.g. with

admin

and whenever you want to check if a user is can e.g. edit something you have to check both the regular

edit

permission and the

admin_edit

and when an admin just want to list projects they are involved with they would list just based on the

view

but when they want to see everything they would list based on

admin_view

but i don't like this approach as it bloats the schema

yetitwo

09/22/2025, 2:13 PM

what you're describing sounds sane to me

yetitwo

09/22/2025, 2:13 PM

i'm not sure what the alternative would be

yetitwo

09/22/2025, 2:14 PM

i guess if we had something like https://github.com/authzed/spicedb/issues/1317 for checks as well it would let you supply the organization relation as a filter

yetitwo

09/22/2025, 2:15 PM

but as it currently stands, adding admin variations and then checking those specifically is the way i would go

yetitwo

09/22/2025, 2:15 PM

if you just want to break things up, you could use the

partial

feature from composable schemas

Conviley

09/23/2025, 9:18 AM

Okay thanks for the sanity check 🙏

Conviley

09/23/2025, 9:19 AM

yeah that issue details something very requested, looking forward to the day it comes! 😄

sp132

10/02/2025, 8:33 AM

We had a similar scenario and solved it like this: definition core/group { relation system: core/system relation owner: core/user relation member: core/user permission view = system->view_groups + owner + member permission membership = owner + member } Direct memberships are queried via the

membership

permission and

view

handles both cases, direct and indirect.

6 Views

Previous Next