except practically speaking: yes

you should always be issuing checks from

permission

for this exact reason

it allows you to change how they are computed without data changes

I'm new here. I've played in the sandbox and have a decent working understanding of how Zanzibar works, your DSL for specifying relations, etc, but I'm afraid that didn't make sense to me. We're a moderately large enterprise, and expect to distribute the responsibility for adjusting permissions to managers through the organization for agility. Distributed responsibility means increased risk of error. I'm trying to understand if we have a facility for an administrator to come in and say "not sure what you did, but I didn't like it, let's go back to the world as it was 20 minutes ago"

are you intending all permissions to be dynamically defined?

via caveats, you mean?

via user defined roles or something similar

most, not all

for example for seat-limited licenses, they have to be granted individually

if everything is going to be directly data driven, including how the permissions themselves are computed, then no, there isn't really a form of "rollback"

because its not schema updates; its adding and deleting relationships

yep, that's what I interpreted from your first response - literally the first feature I want you guys don't support out of the box

thx

not sure how you would expect that to work

any form of "rollback" to a point earlier in time could easily break someone else's changes

you can read relationships at an earlier point in time and just... adjust the changes

i don't expect permissions to change frequently, so eg. rollback to the zookie - er zedtoken - if there are no subsequent changes

it's obviously an edge case. i'm just spending a fair amount of time thinking through on recovery from catastrophic permissions issues

could you clarify what this meant? I don't track "issuing checks from permission"

if you have a schema like:

definition resource {
  relation viewer: user
  permission view = viewer
}

you should always issue a check to

view

, not to

viewer

yep, 100%

got it

and what did you mean by "dynamically defined" here?

using something like user-defined roles, vs having all the roles and permissions defined directly in schema

heh. honestly hadn't even considered that. I see the utility but don't think it's a match for our needs.

under the assumption that you're Joey Schorr - mind if I ask a couple questions about the design of your Schema DSL?

not sure if that's appropriate here

yep, and sure

minor: why do you use ":" for relations and "=" for permissions? seems a needless distinction