-
Notifications
You must be signed in to change notification settings - Fork 297
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LookupResources, through object(s) #1317
Comments
@jwineinger in your example, is the filter "comes from the org#member" or is it "the |
@jwineinger and what if a resource is under multiple organizations? I assume you still want it returned? |
I don't believe I have that use case. However, I think that is what I would expect; if the object is reachable in the filtered/restricted subgraph, then yes, it should be returned. |
Hi, I have a similar use case, which is even a bit more complicated. I want to filter the "user to folder" relationships by a "folder to folder" permission. More specifically, I want to lookup permitted children (subfolders) of a specific folder. It is actually a combination of two lookup params:
My schema: I am currently using the two lookupResources commands above and filter the responses. However, it would be nice (and maybe more performant) to make just one call. |
@jwineinger Coming back to this after some recent LR work; do you want it to be filtered by a specific resource or a resource+permission (such as organization:org1#view)? I think with the new experimental LR implementation we could early shear out results that don't reach "through" a resource or a resource+permission; trying to decide which is closer to your requested goal (I think just a resource?) |
From what I know today, resource+permission will fit our use-cases better in my head that sounds like: Find all (resources) posts in (the subtree) organization:org1 that user john can (permission) read |
@benkroeger in your above example, the permission is |
Now I see what you mean. So it's resource (organization:org1) only |
FWIW, we have the same use case and only the resource should suffice as well. In our case it's like the GCP IAM model, but imagine limiting the lookup to resources reachable within a certain folder or project. |
Okay; with the work we've been doing as part of LR2 (see: #1905), this might be a fairly straightforward thing to do as a followup; I'll have to give some more thought to the exact approach when intersections/exclusions are involved, but LR2 does open up the possibility. |
We have a use case similar to this as well. We have a distributed system with multiple organisations. Projects span across multiple organisations for collaboration. Documents both belong to a specific organisation, but can be shared across organisations by adding them to a project. In our case, I want to lookup the specific documents in org:b that a user in org:a can view, via project:x. |
I need a way to do a lookup resources request but only select results from a subtree/subset of the user's actual access.
The use case is that a user might be related to many organizations, and might have access to many documents on those many organizations. I want to query for the documents the user has access to, but only for one organization at a time. Getting them all is not necessary, and likely very undesirable from a performance standpoint since there could be a rather large data set for each subtree.
I may want a UI to show the user's access in the context of a single org, or do a authz-aware data export in the context of an org. In either case, I only want/need the one org's data, even though the user legitimately has access to a much wider set of resources of that type (through other orgs).
Sample schema and relationships: https://play.authzed.com/s/xkAf0Jir39ZB/schema
In this case, I want to be able to query for a single partnership's documents (with respect to the user), so I'd only want to get
org2-invoice
ororg1-invoice
at a time, not both.Semantically, this feels like a request for "LookupResources, through object(s)". Excluding object(s) might be useful, along with analogous operations for LookupSubjects queries, though I don't currently have need for these.
Link to brief discord discussion: https://discord.com/channels/844600078504951838/844600078948630559/1106613923358199931
The text was updated successfully, but these errors were encountered: