A quick question around when to use scopes vs hierarchal naming for resources: Let's say I have an experience that's largely config-driven, and certain roles can modify certain parts of that configuration. As a simplified example, say a product manager can take actions on products, and a marketing manager can update content, colors, assets etc in different parts of the configuration. I see two ways this could be modeled: 1. Hierarchal naming of the resource (a base policy for

config

, a policy for

config:products

,

config:somePart:content

) 2. Scopes (

kind: config, scope: 'config.products'

) 3. A mix of the two? Is it right to say that scope should be resource agnostic, and preferred for things like multi-tenancy? What are the trade-offs of modeling it in one manner or another? What sort of litmus would you use to pick? I appreciate any insight you might provide! Thanks again for a great intro to the community today

Based on your description, if you're mostly dealing with actions and sub-actions, I think you might find hierarchical naming a little bit more easier to deal with because you only need a single policy file for that. If you use scoped policies with the scope set to the action, you'd end up with a lot of policy files that might be difficult to manage.

Very useful insight, thank you! I actually didn't realize you can define hierarchically named resources in the same file

Have a look at this example in the playground if you want to see how scopes work https://play.cerbos.dev/p/gE623b0180QlsG5a4QIN6UOZ6f3iSFW2

In the expense example, the actions are are nested but could you have a nested resource of some

expense:partOfExpenseReport

?

It is completely open for you to define your own convention so would work aslong as your codebase using the same values