Prisma how to run other queries as findMany

[13uraksahin]

Is your feature request related to a problem? Please describe.
We cannot use accessibleBy with prisma's findUnique, update and delete functions.
When we use accessibleBy(ability).ModelName it gives this result: { OR: [ { uniqueValue: 1 } ] }
However what we need is only bare object: { uniqueValue: 1 }

Describe the solution you'd like
So, what I do is:
I also use params in the conditions... if there is param it adds and if there is not it leaves conditions alone:

To define:
can('read', 'post', { authorId: account.id, ...params }); (if there is any param it will add, and if there is none, there will be only authorId) - (Also ...params part is not the topic but this example shows that if casl solves the problem, how easy the implementation is) - (Also, we can even write conditions with operators like AND / OR)

prisma.post.findMany({ where: accessibleBy(ability).Post['OR'][0] })
prisma.post.findUnique({ where: accessibleBy(ability).Post['OR'][0] })
prisma.post.update({ where: accessibleBy(ability).Post['OR'][0] })
prisma.post.update({ where: accessibleBy(ability).Post['OR'][0] }) // runs if no foreign key constraint exist

(Also need to use // @ts-ignore if using with TypeScript)

We should not be writing ['OR'][0] to the end (also I do not think that anyone writes 😄)... and accessibleBy(ability).Post should be enough.
Are there any reason that casl does not provide bare object rather than default added OR array inside of an object? Because bare object will solve 95% of cases which people can face isn't it?

[stalniy]

Casl wraps everything in OR because in case of multiple rules for the same action/subject type they are OR-ed.

I can optimize it for single OR condition but then your whole app may be broken because at some point in the future you may add additional condition.

So I’d not rely on the shape of the conditions casl returns you back

[13uraksahin]

Hmm, I got the point. Correct as fundamental.

However, without any extra or (or anything else), we can also add our own AND or OR conditions, and with the proper documentation, this can be understood and used by developers much more easily. Should it really be OR-ed by default while I can write myself? Because we have the @casl/prisma package, but we cannot use with the prisma if we won't use findMany or findFirst, (I mean we really cannot use with prisma). Also, I am not sure, but this can be done with casl because doc only shows how to write findMany and this update won't affect findMany.

What I suggest makes us to be able to:
We can add all types of conditions to the conditions inside can/cannot which will create accessibleBy(ability)
We can add all types of conditions to the prisma where object
We can combine both of above
Won't violate the fundamentals
Won't break the apps written with documentation

I think this is easier while brings much more possibilities to the code. And I think it does not violates the fundamentals. We still create.

[jbeckton]

I am finding that CASL in a typescript app to be nearly unusable. If you are protecting routes as well as Prisma queries there is no way to reuse any code between the two use cases. So, as you add models to your Prisma schema you have to update both sections of code. Then there is the issue of user permissions. If you create a permission array for the route guards, so that you can generate mongo abilities, you cannot also use that permissions array to create the prisma ability. So I have to convert the user permissions data to some other format in order to use it with the prisma integration.

[stalniy]

@jbeckton I don't understand your issue. You can open discussion and prepare an example of what you are trying to achieve and why you can't reuse the same rules to protect queries and routes. You can find an example of how prisma can be used with fastify and casl -> https://github.com/stalniy/casl-examples/blob/master/packages/fastify-prisma-blog/src/modules/articles/routes.ts