you can't call LS on the group, as its a terminal

in your case above, the change is applied to an arrow

so it has to be handled slightly differently

are you trying to implement LookupWatch yourself?

yep, at least a really streamed-down version

why? (just curious)

also, LookupSubjects isn't in the API just yet: I'm working on the final touches of it now

> also, LookupSubjects isn't in the API just yet: I'm working on the final touches of it now Yeah, I'm aware of that, that's really cool > why? (just curious) We need a solution for our apps to show to the user only the data they are entitled The only way for cases with lot of data is this Lookup Watch API Hence only question remaining is why we do the job ourselves We need this kind of solution quickly (to rely on that in our apps). The implementation on our apps side needs to de bone under in 3 months. We're trying to do a quick and dirty work of doing the start of the implementation in 3 weeks (really not sure we'll succeed in anything, but still...), to know if the thing would work (once more, not a full blown implementation, so, no cache, no big data, etc...) In parallel, I contacted my hierarchy to know if we can pay you to implement the real thing (or at least contribute financially), but as of now, no answer So here we are...

gotcha

so yeah, you've stumbled upon the one harder issue with the design: arrows

in the above case, if you see a relationship that affects an arrow (which you can only know by knowing and parsing the schema), then you need to issue a different set of queries

which is non-trivial, I'm afraid

basically, in your example, you'd take the right side of the relationship, find all associated resources for which the group is a

parent

then for those, you'd issue your check updates

basically: your arrow reads

parent->read

so your LookupSubjects is in fact to permission

read

for the resource group

Thanks for your insights @Joey I need to think a bit more about it (lol) I would have expected just to extract the subject part from the Watch API response and call LS based on that (and LS querying all relations with resource_group:G1 as the resource part and recursively continue until getting a relationship having the requested subjectType)

yeah, that's how it works for everything but arrows; arrows are special

because they are, well, indirect

Sorry @Joey just to be sure I understood, if I remove the relationship

resource:F1#parent@resource_group:G1

After parsing correctly the schema and seeing the arrow function, I would have called LS with:

LookupSubjectsRequest {
  ObjectReference: {
    ObjectType: resource_group,
    ObjectId: G1,
  },
  permission: read
}

Is that right ?

I believe so, yes. That would find any users that can read the group, and in turn allow you to check them for the resource

Thanks !

Hey, just ran into this problem. Any idea when that will be supported?

its on the backlog but not yet fully scheduled

for now the recommendation is the workaround documented

are there specific documents outlining spicedb installations on various cloud platforms (gcp)

Hi @Joey I'm working with @tartignolle. Just to be sure that I understand. Tbo while reading the whole conversation with my team mate I just realize that I didn't get it >< I thought that the whole process of the Lookwatch Api can be sum up like this : 1. Receive notification from watch api following this schema : resources#relation@subject 2. Call LookupSubject to get all Subject of a chosen SubjectType link to the subject send by watch Api. (I wondered that this api recursively get all relation relate to the subject until find the correct subjectType) 3. Do the same as 2) for the resources send by watchApi. Aka the left side of expression. 4. Cross join the 2 responses 5. Call checkPermissionApi on all elements of 4) link with one specific relation With this process do we resolve the "arrow issues" ? Do checkPermissiknApi correctly solve the permission crossing the schema and so the arrows ? I guess I miss something maybe perf maybe something else. Surely my eyes refuse to see something obvious to keep the work as simple as possible :p

that is all correct except in the case where the relationship is on an arrow

in that case, you'll need to grab the permission from the right side of the arrow

check permission does walk arrows properly