it does take into account the schema

right, I think that was my understanding: you feed a given schema, and the systems behaves accordingly.

I took if as "if you you are working on a schema, and something is not working as you expect, a good place to start may be running the consistency tests"

usually if you're developing a schema though you want to assert that certain properties of your schema are true, e.g. readers can read but they can't write

and you usually start from the assumption that spicedb is implemented correctly

right. There are at least 2 paths to achieve that, as far as I can tell: - write integration tests that spin up spicedb (docker or from compiled binary) - reuse playground YAML to run assertions (no API for that, currently working on what it could look like)

yep, sounds good

is

spicedb validate

really a command y'all be OK exposing in the

spicedb

CLI?

playground YAML is already exposed as part of the CLI contract with

SPICEDB_LOAD_CONFIGS

so it wouldn't be too far off, but somehow it feels like not the kind of command one would expose in

spicedb

CLI

perhaps

spicedb serve-devtools validate

? 🤷🏻‍♂️

@User I believe so. Here is the issue if you'd like to add your suggestions and use cases: https://github.com/authzed/spicedb/issues/290

thanks for opening it 🙂

I have working code locally, but the challenge is what kind of API y'all feel comfortable exposing

exposing it as go code is tricky because there is a bunch of

v0

code involved 😦

yeah, my (personal) preference is to have it take in the validation YAML

as a file, which we also already support for the initial load

and then we can extend the validation YAML format to make it easier to write or something to that effect

that sounds good to me. I had created a function like this

func ValidatePlaygroundYAML(playgroundYaml []byte) ([]*v0.DeveloperError, error) {

I think I can work on

spicedb validate

and show a prototype to see if it goes in the right direction

@User I think that would be valuable, yeah

PR incoming!

oh I see that spicedb-dev may be a better place for this kind of discussions?

yeah, we should probably move it into there

Hello! Quick question... Is there a recommended way to model something like a staff user that has permissions for lots of different objects, without having to create relations in all the objects where a staff user has permissions?

is the staff user's permissions "global" or attached to something else (like, say, an organization)?

global

generally, the recommendation in that case is to have some sort of root type, like

system

or

platform

connect your items to that, and then place the staff user permission on the root object

so say you had

resource -> organization