-
-
Notifications
You must be signed in to change notification settings - Fork 346
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
OPL traverse.(...) not working #1330
Comments
Wait.... I've been struggling with something similar. My feeling is that the current version of keto is totally broken for anything other than one step removed. |
Hey, sorry to hear that there's an issue. The primary engineers are currently in completely different contexts but we'll try to get this sorted soon. We're currently swamped with some other work, but obviously it's not acceptable to have such faults. |
@aeneasr any updates here? It's been over a month now. |
Unfortunately our engineers are still busy with other work from customers and we do not have capacity to work on this at the moment. |
I just stumbled over this issue and I had a similar problem, however, I don't know if this was supposed to work or the documentation is outdated but if you specify the namespace in the tuples it should work just fine: [
{
"namespace": "Folder",
"object": "folder_1",
"relation": "viewers",
"subject_set": {
"namespace": "User",
"object": "user_1"
}
},
{
"namespace": "Document",
"object": "document_1",
"relation": "parents",
"subject_set": {
"namespace": "Folder",
"object": "folder_1"
}
}
] When then calling
instead of
it will return |
Any updates? This seems like core functionality of OPL... |
|
This bug actually makes OPL completely useless. Please prioritize this bug as soon as possible. |
This is the answer ^ Think of it as a sort of strict type. Problem with the approach you have tried is illustrated simply by adding another namespace to the
This behaviour must be a part of the design, if namespace is not defined system should create it in same namespace the object is located at. |
Preflight checklist
Describe the bug
I'm trying to check the permits using the traverse.(...) functionality with a very simple OPL model, but it always returns
"allowed": false
.This is my OPL model:
And these are the relation-tuples that I have:
So,
Folder:folder_1 is parent of Document:document_1
, andUser:user_1 is viewer of Folder:folder_1
. I would expect thatUser:user_1 can view Document:document_1
, but it returns false.Reproducing the bug
When making the following request on Postman:
http://localhost:10006/relation-tuples/check?namespace=Document&object=document_1&subject_id=user_1&relation=view
I'm getting:
and I expect it to be
true
. I've also tried adding an extra query parameter likemax-depth=10
, but I'm getting the same resultJust for checking, when I make the following request:
http://localhost:10006/relation-tuples/check?namespace=Folder&object=folder_1&subject_id=user_1&relation=view
I'm getting:
Which is the espected return value, since
User:user_1 is viewer of Folder:folder_1
Relevant log output
No response
Relevant configuration
Version
service_version=v0.11.1-alpha.0
On which operating system are you observing this issue?
Windows
In which environment are you deploying?
Docker Compose
Additional Context
No response
The text was updated successfully, but these errors were encountered: