Hey everybody, I was going through the
# spicedb
m
Hey everybody, I was going through the documentation and came to definition where I have a question for.
Copy code
/** user represents a registered user's account in our application */
definition user {}
 
/** organization represents an organization that contains documents */
definition organization {
  /** administrator indicates that the user is an admin of the org */
  relation administrator: user
 
  /** view_all_documents indicates whether a user can view all documents in the org */
  permission view_all_documents = administrator
}
 
/** document represents a document with access control */
definition document {
  /** docorg indicates that the organization owns this document */
  relation docorg: organization
 
  /** reader indicates that the user is a reader on the document */
  relation reader: user
 
  /** writer indicates that the user is a writer on the document */
  relation writer: user
 
  /** view indicates whether the user can view the document */
  permission view = reader + writer + docorg->view_all_documents
}
Why is there a need for a permission in the organization definition, why can't I (in the document definition, view permission) just directly refer to docorg->administrator?
Copy code
Info: It is recommended that the right side of all arrows refer to permissions, instead of relations. This allows for easy nested computation, and is more readable.
I also found that info, but I don't understand why it allows for easy nested computation and also IMO it's not "more readable" because for me it's confusing that a permission for a definition (in this example document) is stored somewhere else than the definition it gives access to.
j
> hy can't I (in the document definition, view permission) just directly refer to docorg->administrator?
you can
but then if you want to later change
administrator
to be a computed permission
now you need to change all call sites
so we recommend always arrowing to a permission
> is stored somewhere else than the definition it gives access to
it would be a permission right next to the relation
permission can_admin = administrator
y
same deal if you needed to change the permission of
can_admin
- like if you wanted to add some sort of superuser administrator to the mix and add a
+ organization->superuser
m
> but then if you want to later change
administrator
to be a computed permission Is that something you observe often and what can be the reason / rationale behind it? > it would be a permission right next to the relation > permission can_admin = administrator With your example right, but with the example I provided from the docs you create a permission "view_all_documents" which, IMO, should belong to the document definition and not to organization. Because in the example you create a permission for a definition outside of that said definition. I understand why it works but doing it like that, for me personally, looks counter intuitive.
j
> Is that something you observe often and what can be the reason / rationale behind it? Yes
its an org-level permission
document:whatever#view_all_documents@user:tom
doesn't make sense
organization:someorg#view_all_documents@user:tom
does
(sorry, misread your question; its not nested)
11 Views