You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Two levels of organizational units: spaces, which contain projects.
User must be able to get role on project without having to get any space role.
User has to be able to read basic info about parent space (title, etc.).
Right now what we do is we define service role on space, which we hide from main business logic, and this role is added/removed when user roles on projects change.
entity user {}
entity space {
relation role__user @user
relation service_role__projects_user @user
permission view = role__user or service_role__projects_user
}
entity project {
relation resource__space @space
relation role__user @user
}
Or, instead, we could do the same with space-project relations, instead of roles with the same result.
Anyway it feels like a hardcode.
It would be nice to be able to solve this by schema itself, by being able to reference the inverse relations on the fly.
entity user {}
entity space {
relation role__user @user
// Space user or user of any child project (syntax example)
permission view = role__user or project->resource__space.role__user
entity project {
relation resource__space @space
relation role__user @user
}
The text was updated successfully, but these errors were encountered:
mmx86
changed the title
It would be nice if by specifying some relation we could use it as indirect inverse relation in schema
Inverse relations support
Aug 3, 2024
Hi @mmx86, in the use case you provided, we can simplify the permission setup by updating the definition of the relation between project and space by relocating the resource__space relation, we can achieve a more straightforward permission statement that still will satisfy your intent.
i think instead of increasing the complexity of the checks with inverse relations, we can create a more robust schema to address this. if you can provide more details about your actual use case, we'd be happy to help refine the schema further.
Hi, @ucatbas, By relocating, do you mean relocating resource__space relation to space?
The example above omits that that there are permissions in project entity, depending on this relation as well. I should have mentioned that. So it is symmetrical two-directional dependency.
The point is that sometimes we need two-directional relations in complex cases. And we either have to support it in our business logic (extra work, repetitive, prone to consistency errors) or we could support it with engine itself on syntax level.
Right now our team marks through naming that a certain relation is inverse to another and we create/delete it along with the direct one. We have to think about the atomicity of these operations, which creates additional complications.
Hi @mmx86, I meant adding a relation in space entity instead of project entity but as i understand it will not be enough in your case. This feature can be useful for bidirectional relations as your use-case. Let's discuss this further in a thread on our discord channel or dm(ucatbas)
Our usecase requirements:
Right now what we do is we define service role on space, which we hide from main business logic, and this role is added/removed when user roles on projects change.
Or, instead, we could do the same with space-project relations, instead of roles with the same result.
Anyway it feels like a hardcode.
It would be nice to be able to solve this by schema itself, by being able to reference the inverse relations on the fly.
The text was updated successfully, but these errors were encountered: