So how come when I navigate to the sample playground I see the ending arrows: https://play.authzed.com/s/qF3yzgbAVj7U/schema

But when I plug the same schema into a pristine playground, I don't see the ending arrows?

the visualizer uses the test relationships to determine where arrows actually exist

if you have no test relationships, then none of the relations actually connect to another

ah ok.

to show that, comment out the test relationship you have in ^

you'll see the arrow disconnect

and if you hover over the white dotted arrow

it shows which relationship(s) exist to form that connection

So - can the system visualizations from the playground be exported?

nope, not as of today

We'll likely need it for SOC2 reporting

interesting, what format do you need it in (vector, raster)? do you anticipate making any changes manually before or after exporting?

Vector, PDF would be fine. It would be amazing if we could export to lucidchart and tweak before creating the final document but not necessary.

doesn't seem like there's any kind of standard interchange format for this

Yeah I'm not surprised

looks like draw.io is at least open source

not sure how quickly we might be able to get to any sort of solution here

Yeah that's fair, plus I'm not a paying customer so no rush

I have a quick question about the idea of validations with spiceDB. I’m wondering what the guidance is to include validations as part of permissions in the schema vs. doing them at the time relationships are generated, e.g. the data is written. Let me give you an example… I’m implementing the idea of a ‘repository unlock’ where a staff user is given access to a repository. All I really need to know is that the user has been granted this ’repo unlock’ to assign them some permission, which looks like:

definition github/repository_unlock {
    relation unlocker: github/user

    permission access = unlocker
}

definition github/repository {
    relation unlock: github/repository_unlock
    permission manage_settings = unlock->access
}

However, there is a validation that says that a user cannot have a repo unlock unless they are a staff member. I think I could model that by:

definition github/site {
    relation staff_member: github/user
    permission staff_access = staff_member
}

definition github/repository_unlock {
    relation unlocker: github/user
    relation site: github/site

    permission access = unlocker & site->staff_access
}

That, however, comes with the big tradeoff that I have to create a relationship for every repository_unlock object to the site (I think a wildcard would help here but that’s another story). If I removed this staff member “validation” in the permission check it is something I could check instead at the point I’m generating the repository_unlock unlocked relations and leave it out of the schema. WDYT?

you could do so at generation time, but the general recommendation for safety is to do so at runtime if it is a hard permissions requirement

which here it appears to be

could you put the unlocker on the repo itself?

yup that works! hadn't thought of that

I think i'll still need to add a

relation site: github/site

to add the

site->staff_access

check in the repo permission. A repo can be org owned and I do have a site relation there, but it can also be user owned and there is no

site

relation on the user.

so its either put it on every user or put it on every repo I think

one idea would be to have the repos live under a

namespace

type