@definitelyBenny I agree. We're
# spicedb
j
@definitelyBenny I agree. We're scheduled to add more to the examples repo over the next few weeks
d
(If any of my scenarios are already handled, please feel free to tell me haha)
How to take cascading permissions and optimize them to prevent duplicate checks (eg: If a user has edit, they also have view, and if they have admin they have edit and view) Bonus points if you can show how to integrate non cascading permissions into this (eg: Admin gives view and edit, but not share) How to handle default permissions on a resource. (eg: Group Y immediately gets admin rights to every resource (event newly created ones) while Group Z only gets view rights Just some thoughts, more to come
j
first one is fairly straightforward
Copy code
definition resource {
  relation admin: user
  relation editor: user
  relation viewer: user
  relation sharer: user

  permission can_admin = admin
  permission edit = editor + can_admin
  permission view = viewer + edit
  permission share = sharer
}
^ any admin can also edit and view but not share
default permissions you handle by writing a relationship to a singleton:
Copy code
definition kind {
  relation admin: user
}

definition resource {
  relation admin: user | kind#admin
  permission can_admin = admin
}
then write
resource:whateverresourceitis#admin@kind:resource#admin
and
kind:resource#admin@user:fred