https://authzed.com logo
Join Discord
Powered by
Caveats & Not
# spicedb
m
I’m curious if anyone can help me spot a new way to look at something I am trying to represent in SpiceDB. I’ll post a simplified example in a thread and ask my question but I’d appreciate both direct recommendations and also any RTFM links or blog posts you think I should have a look at 🙂
Here’s a simplified schema for me to talk to:
Copy code
definition user {}

definition project {
  relation admin: user
  relation member: user
  relation approver: user
  relation view_only: user

  permission write = admin
  permission view = write + view_only + member

  permission approve = view - view_only
}

definition workspace {
  relation project: project
  relation project_viewers: project#view with is_public_workspace

  relation workspace_admin: user

  permission write = project->write + workspace_admin
  permission view = write + project_viewers
  permission approve = view & project->approve
}

caveat is_public_workspace(workspace_is_public bool) {
  workspace_is_public
}
The question is: can I represent this any differently to avoid the current need to create two relationships on 
workspace
for the same 
project
(one caveat we and one not). The crux of this is a need to both (a) represent a relationship that depends on whether the 
workspace
is public and also (b) access some permissions from the related resource regardless of whether the 
workspace
is public. Both relationships will be to the same 
project
but you will note above that the caveated relationship is used in one way and the uncaveated relationship is used in another way and needs to register as permissive even when the caveated relationship does not.
j
if it is just for making it public
use a wildcard to represent thatr
relation project_viewers: user:*
write that relationship and any user can view the project
making it public
m
Is your suggestion to conditionally write the 
project_viewers
relationship when the workspace becomes public and then delete it when the workspace becomes private? The fact that it can flip between public and private was my initial reason for reaching for a caveat.
j
yes
unless you expect the public/private status to be changing every request
which I imagine is not the case
caveats should generally be used for dynamic conditions
m
Ok. Thanks. That’s another idea I had briefly looked into but it helps to get a recommendation to push me in that direction. Out of curiosity, would there be performance implications to a kind of hybrid idea if I ended up liking the semantics of it? 
relation project_viewers: user:* with is_public_workspace
Maybe it isn’t idiomatic (which is worth noting), but would it also just be a bad idea on performance grounds unless it was needed?
j
caveats add overhead onto checks because the expression has to be executed
its not a huge amount, but it is overhead
m
Gotcha. Thanks so much!
j
so unless there is a solid reason to do so, I'd just go with the wildcard
like if the condition is more than a binary "public" vs not
PreviousNext
Powered by