New Features
1. Comparing fields from different models in mutation policies #1463
Previous versions of ZenStack had an unintuitive limitation that you can't compare fields from different models in policy rules. E.g., the following snippet was not valid:
model Post {
...
org Organization @relation(...)
orgId Int
author User @relation(...)
authorId Int
@@allow('update', orgId == author.orgId) // orgId and author.orgId are from different models
}This release partly resolved the limitation by supporting such comparisons in mutation rules ("create," "update," and "delete").
Cross-model field comparison is not natively supported by Prisma, so ZenStack has to read the data out of the database and check the rules in the JS runtime. When ZenStack identifies a policy rule that involves such a comparison, the entire rule will be evaluated "post-read". Although it's usually not a big deal for mutation operations, you should be aware of the performance impact. For best performance, put expressions involving cross-model comparison into separate policy rules (so that other rules are still evaluated during database queries).
Cross-model field comparison is still not supported in "read" rules for two reasons:
- It's very easy to result in reading an unbounded number of rows, filtering and discarding most of them.
- It should be noted that "read" rules cover not only find but also aggregations. If we can't do a filtered aggregation on the database side, we'll have to reimplement it in the ZenStack library.
Please provide feedback in our discord if it's important for you.
2. Added support for Prisma 5.14's new createManyAndReturn API #1461
The returned results are properly filtered by access policies.
3. Relation filtering now respects field-level policies #1454
Background: ZenStack's "read" policy rules control not only what data you can retrieve but also how filters work. For example, in the following schema and query:
model Post {
...
deleted Boolean
@@allow('read', !deleted)
}db.user.findMany({ where: { posts: { some: { published: true } } } });Post model's read rules will be injected into the where clause, like:
db.user.findMany({
where: {
posts: {
some: {
published: true, // user-provided filter
deleted: false // ZenStack injected filter
}
}
});In previous versions of ZenStack, such filter injection only respected model-level policies but not field-level ones. This release fixes this missing part. For fields involved in filters, if they have field-level "read" rules, those rules will also be combined into the final filter. The consequence is, for the above example, if the published field is not readable, the findMany will result in an empty array.
The injection also respects "override" field-level rules, meaning that even if the Post model is not readable, but you have a field-level "read" rule for the published field that overrides the model-level policy, the published field can be used in the filter.
Fixes and Improvements
- Fixed Windows build issues and improved contribution documentation by @WimTibackx
- Fixed default value handling for BigInt type in Zod schemas by @aloisklink
- Upgraded Prisma peer dependency to <= 5.15.x
- Fixed typing issues in TanStack Query's infinite query hooks #1472
- Fixed typing issues in TanStack Query hooks generated for Svelte #1488
- Fixed overlong identifier names generated in Prisma schemas generated for polymorphic models #1466
- Fixed incorrect validation errors for polymorphic models inherited from an abstract base model #1474
- Fixed Decimal/Date object corruption when used with polymorphic models #1487
- Fixed runtime error when using polymorphic models with optional relation fields #1483
Docs Updates
-
Clerk integration guide now has sample code for Next.js app router
https://zenstack.dev/docs/guides/authentication/clerk#create-an-enhanced-prisma-client
New Contributors
Welcome @WimTibackx and @aloisklink as our new contributors!
Full Changelog: v2.1.2...v2.2.0