-
Notifications
You must be signed in to change notification settings - Fork 8
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
deduplicate edges when conditions exist and add conditions to the edges #422
Conversation
Co-authored-by: Yamil Asusta <[email protected]>
Co-authored-by: Yamil Asusta <[email protected]>
Co-authored-by: Yamil Asusta <[email protected]>
@@ -83,7 +83,8 @@ func (g *AuthorizationModelGraph) Reversed() (*AuthorizationModelGraph, error) { | |||
if !ok { | |||
return nil, fmt.Errorf("%w: could not cast to AuthorizationModelEdge", ErrBuildingGraph) | |||
} | |||
graphBuilder.AddEdge(nextLine.To(), nextLine.From(), casted.edgeType, casted.conditionedOn) | |||
newEdge := graphBuilder.AddEdge(nextLine.To(), nextLine.From(), casted.edgeType, casted.tuplesetRelation, "") | |||
newEdge.conditions = casted.conditions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not graphBuilder.AddEdge(nextLine.To(), nextLine.From(), casted.edgeType, casted.tuplesetRelation, casted.conditions)
?
if graphBuilder.hasEdge(nodeSource, parentNode, TTUEdge, typeTuplesetRelation) { | ||
// de-dup types that are conditioned, e.g. if define viewer: [user, user with condX] | ||
// we only draw one edge from user to x#viewer | ||
continue |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to call upsert? Otherwise, will be lose the condition?
type permission | ||
relations | ||
define assignee: [role#assignee, role#assignee with condX] | ||
define member: [user, permission#member, permission#member with condX] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will be easier to read if they line up :)
require.Len(t, edges, 1) | ||
conditions := edges[0].conditions | ||
require.Empty(t, edges[0].tuplesetRelation) | ||
require.Len(t, conditions, 2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we assert on the conditions itself? (i.e., check the individual array item)
* feedback from github.com//pull/422 * Update pkg/go/graph/graph_builder.go Co-authored-by: Adrian Tam <[email protected]> --------- Co-authored-by: Adrian Tam <[email protected]>
Inconsistent behavior in the parser was deduplicating the edges if directly related to the terminal type but not in the case of a userset, causing the algorithms in the type system to not identify models that should have fast path
Description
The parser was deduplicating cases like the one below, where it only constructs one edge from group#member to user:
type group
define member: [user, user with condX]
In the case of a userset with conditions it was not behaving in the same way, and it was creating two edges from group#member to folder#viewer
type group
define member: [folder#viewer, folder#viewer with condX]
type folder
define viewer: [user]
This PR covers the following changes:
1- Add the deduplication for the userset case
2- rename conditionOn on the edge to have a name that represents its value, tupleUserset, in a ttu (X from Y), it is the Y
3- add conditions to the edge, to add more info required to substitute in the future the type system and use the graph
4- Add tests that cover all these changes
References
Review Checklist
main