Drilling down a bit more on how one might combine ...
# spicedb
Drilling down a bit more on how one might combine multiple caveats, if my tuples had a context with a "from" and "to" timestamp, and the check came with an "at" timestamp. Would this be how I check that the "at" falls between the "from" and "to"? definition user {} caveat hasStarted(timestamp from, timestamp at) { from.Before(at) } caveat notEnded(timestamp to, timestamp at) { to.After(at) } definition resource { relation linked: user with (hasStarted && notEnded) permission canAccess = linked } I am not familiar with CEL, are all these fields nullable? What would the behaviour be if the "to" field was null?
looking at https://github.com/authzed/spicedb/pull/1125/files#diff-503ae19335b62bfd47dee88ff9fd175035cf7c565bda6a1eadabe3b41b7e5be1 something like https://play.authzed.com/s/E6-BZWTWrn0y/relationships should be possible (caveats should work in the playground, doc still states they don't) - but I get the error
proto: invalid type: time.Time
when running the assertions. Dunno if bug or wrong syntax, but interesting question 🙂
https://play.authzed.com/s/wD2h8YcFo1mZ/schema @Joey @vroldanbet is it possible the playground is not playing nice with timestamp caveats, yet? see link above, I essentially copied the schema, relations and assertions from the test and i always get the error mentioned above.
hah, indeed I think Joey fixed recently something with the way time is parsed, but I thought we deployed it recently
but maybe it requires yet another fix in the playground
@MattA back ti your question, you cant use expression language after
keyword. You can only use it to reference a caveat
you'd have to combine all that logic in one single caveat definition
and for timestamp operations, you can use comparison operators like
<, <=, ==, !=, >, >=
Thanks all. Not sure why, but I thought the caveat checked one context variable from the tuple against one in the check. Makes perfect sense that it can use the names to access any variable. It does raise the question "what would happen if you had a variable with the same name in the tuple context and the check context?"
Tuple takes precedence
I hope these questions are helping the documentation writing process 😄