Augustin

@Jonatthu Did you intentionally close this issue?

In `policy`, I am thinking of adding a `permissions` property that should look like this: ```ts function permissionsChecker(args: any, user?: AuthUser) { return { post: { read: { OR: [...

Imagined implementation details / steps: - [ ] Generation of permissions from the zmodel AST, at the same level as other generated policy properties (guard, validation, etc.) - [ ]...

Thinking again about `permissionsChecker()`... I should instead return an object with inline conditions, like this : ```ts function permissionsChecker(args: any, user?: AuthUser) { return { post: { read: args.authorId ===...

For now, the only solution I have is to manually check the property on the authenticated user/resources. This is problematic as it is not synchronized with our zmodel schemas. I...

What I have in mind to build the permissions themselves: 1. Obtain policy rules from the zmodel AST. 2. Resolve each one (with transformation rules below). 3. Build complete conditions:...

Thank you @ymc9 I had not imagined such a use case where we would add constraints/conditions to the permission checker. In my understanding, all 'constraints' were supposed to be present...

To address each of your points: 1. This was the understanding I had following your [comment](https://github.com/zenstackhq/zenstack/issues/242#issuecomment-1841904092). 2. Now that you've mentioned it, I don't see how to skip the "partial...

I compared [kiwi](https://github.com/lume/kiwi) and [Z3](https://github.com/Z3Prover/z3/tree/master/src/api/js) and decided to proceed with Z3 because the syntax is simpler, and there are many missing features in Kiwi (such as the OR condition). Here...

> I went through Z3 documentation and thought about how to model constraints with it too. I've captured my thoughts in this repo: https://github.com/ymc9/z3-exp No, Z3 handles string and array...