hi everyone, i was wondering if it was possible to use caveats to filter relationships at runtime (like if i am in an organization context i want to just see the documents i have access to through the organization). If i were able to get the organization object in the caveat i would be able to filter it i think https://cdn.discordapp.com/attachments/844600078948630559/1231887722818441257/Screenshot_2024-04-22_at_10.39.35.png?ex=66277458&is=662622d8&hm=d86ecd46585eab95af87c2ccf5b32ac19452797f3142ba58e01dc2915d09a276&

Caveats is a mechanism to effectively filter relationships, but you can't get the relationship it's associated to as part of the caveat. What you can do is to store the organizationID as part of the caveat context, but I understand that's redundant. Providing access to the relationshp it's attached to it's an interesting idea tho

it would be to allow the listResources command (for example) to have an optional caveat organizationId and return just the filtered documents if looking for the permission view_in_context. I don't know if I am looking at it from the wrong perspective. Right now I'm doing the filtering at the application level. A document has just one parent organization but a user can be part of multiple organizations

Yeah, what you are describing is https://github.com/authzed/spicedb/issues/1317 which is not currently supported, so I understand why you are attempting to implement it with caveats. What you are trying to do would kinda get you there, except there is no way to get the relationship data into the caveat just yet, you'd have to manually store it yourself as part of the caveat. I don't dislike the idea of generally supporting the relationship as an injectable argument into the caveat, since it's in line with the idea of caveats associated with a single relationship. @Joey what do you think about supporting like a special

Relationship

type that injects the relationship into the caveat at runtime?

its... inverted

it's inverted, yes