Is it possible to return caveats or metadata with a check

[ashley-taylor]

Hello.
We are looking into using SpiceDB. Our existing policy system maps cleanly, with one exception.
We can have arbitrary filters applied to our permissions.
For example,
A user has access to Orders With the following filter ID starts with a
We then calculate the sum of orders the user can see.

There are millions of orders; for performance, we need the a filter in the query.

Would like to model it like a caveat but within information return somehow

Is there any guidance on how a use case like this should be modelled?

[vroldanbet]

If I understand correctly, you must return all orders a user can access with resource_id that starts with a.
You can do LookupResources, iterate over the cursor, and drop any resource_id that does not start with a.

A bit unorthodox but you could add a caveat to the relation that grants the permission, you need to place it strategically in a relation that will result in caveating the Order for the user. This is probably one of those instances where the caveat in the permission could be useful. If you have multiple ways an order is owned, it may get trickier because you have to caveat all the relations through which the user can get access to an Order, depending on your model it may be feasible:

caveat filteredWithID(filter string, actualID string) {
  actualID.startsWith(filter)
}

definition Order {
  relation owner: user with filteredWithID
  permission view= owner
}

Then when running LookupResources you'd pass the context with actualD=a and the server side would return a filtered version of the orders the user can access.