build: add support for identity backlinks to permissions package

[jonbretman]

• Updated permissions package to support backlinks from ctx.identity
• Updated permissions tests
• Added quick integration test for function permissions that uses a backlink

I strongly feel that we should update the runtime permissions stuff to use the permissions package SQL generation so that we can be sure behaviour is the same between runtime and functions. Looking at the runtime code I don't think this should be too tricky as ultimately we just execute some SQL

[davenewza]

I strongly feel that we should update the runtime permissions stuff to use the permissions package SQL generation so that we can be sure behaviour is the same between runtime and functions. Looking at the runtime code I don't think this should be too tricky as ultimately we just execute some SQL

@jonbretman Having two independent expression-to-SQL builders is just silly (which I think we both agree on). But if we do move runtime permissions to use this permissions package, then we still end up with two independent expression-to-SQL builders because @where uses the query builder in the actions package. This means that every time we add a some feature or fix some bug for expressions, we will need to implement it in two places ...we're doubling the work needed.

I am still more in favour of having functions permissions rather use the actions package query builder instead, because then we have one SQL builder AND because I think the action builder package is covering more use cases, has more tests, and should be more battle-hardened by now (by virtue of action @where and @permission expressions having been more thoroughly used and tested and fixed).

I think we're a little stuck on this point. Perhaps it's also due to me feeling more comfortable with the runtime permissions code and you feeling more comfortable with the functions permissions code. But at the end of the day I also just want this unified.

[davenewza]

Looks good!

Maybe we need some tests which test cases such as:

Backlinking to some field:

create createFilm() {
    @permission(expression: ctx.identity.user.isTeller)
}

And something a little more complicated:

create admit() with (film.id) {
    @permission(expression: admit.identity.user.age >= admit.film.ageRestriction)
}

And backlinking deeper down the relationship graph:

create createFilm() {
    @permission(expression: ctx.identity.user.team in film.teams.team)
}

[jonbretman]

I strongly feel that we should update the runtime permissions stuff to use the permissions package SQL generation so that we can be sure behaviour is the same between runtime and functions. Looking at the runtime code I don't think this should be too tricky as ultimately we just execute some SQL

@jonbretman Having two independent expression-to-SQL builders is just silly (which I think we both agree on). But if we do move runtime permissions to use this permissions package, then we still end up with two independent expression-to-SQL builders because @where uses the query builder in the actions package. This means that every time we add a some feature or fix some bug for expressions, we will need to implement it in two places ...we're doubling the work needed.

I am still more in favour of having functions permissions rather use the actions package query builder instead, because then we have one SQL builder AND because I think the action builder package is covering more use cases, has more tests, and should be more battle-hardened by now (by virtue of action @where and @permission expressions having been more thoroughly used and tested and fixed).

I think we're a little stuck on this point. Perhaps it's also due to me feeling more comfortable with the runtime permissions code and you feeling more comfortable with the functions permissions code. But at the end of the day I also just want this unified.

@davenewza if you have an idea on technically how to use the runtime actions query builder (in Go) in functions (in other languages) I'm very happy to discuss it - but personally I can't think of a viable way of doing this. Go's WASM support just isn't there, and calling out to the runtime for every query will be way too slow.

I also think the @where stuff is different - those only apply to non-function actions, but permissions cover both runtime actions and functions.

[jonbretman]

Looks good!

Maybe we need some tests which test cases such as:

Backlinking to some field:

create createFilm() {
    @permission(expression: ctx.identity.user.isTeller)
}

And something a little more complicated:

create admit() with (film.id) {
    @permission(expression: admit.identity.user.age >= admit.film.ageRestriction)
}

And backlinking deeper down the relationship graph:

create createFilm() {
    @permission(expression: ctx.identity.user.team in film.teams.team)
}

Good idea - I'll add some like this.