You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Sometimes i want baked in logic like soft delete mechanism into my model access policy. But sometimes the user/client can still access the data but only in implicit circumstances. Most of this could be implemented through the access policy and passing the parameter to the auth() but then you would need to create a new enhanced client. i believe you might want to enable/disable the access at the transaction level.
To rephrase, sometimes a single user of elevated "role" wants to view the application data the same as other users but by toggling an "flag" they can now include rows previously excluded (ie. archived, deleted)
Key to be passed to 'enhanced' client to enabled/disable filter behavior
condition
Boolean expression to be evaluated/inject if the fitler is enabled
enabled
Boolean indicating if the filter is enabled by default, should not have "args()"
false
modelPost {idString@id@default(cuid())titleStringownerUser@relation(fields: [ownerId], references: [id])ownerIdIntcreatedAtDateTime@default(now())updatedAtDateTime@updatedAtpublishedAtDateTimearchivedAtDateTimecreatedAtDateTime// Filter Annotation will always inject this where clause when accessing model,@@filter('excludeArchived', archivedAt != null, true)@@filter('existingAsOf', createdAt = args().date)@@filter('publishedBetween', publishedAt > args().min && publishedAt < args().max)@@deny('all', auth() == null)@@allow('all', auth() == owner)@@allow('read', auth() != null)}
This could then be used as such:
import{PrismaClient}from'@prisma/client';import{enhance}from'@zenstackhq/runtime';constprisma=newPrismaClient();constdb=enhance(prisma);// then elsewhere ...// this will excludeArchived by defaultawaitdb.post.findMany();// this will disable exclude archived logicawaitdb.post.findMany({filters: {excludeArchived: false}});// this will enable the other filters, multiple should be allowedawaitdb.post.findMany({filters: {existingAsOf: {date: newDate()},publishedBetween: {min: newDate(),max: newDate()}}});
Describe alternatives you've considered
Now some the examples above are contrived and arguably pointless, for example the publishedBetween could/should just be written in the where clause and this layer of abstraction is complicated. I agree, the example was to illustrate the concept.
The real benefit here is for complex use-cases like effectiveDated/Versioned/Temporal models and "version" control, where a filter enabled at the top level will be enabled for relations that invoke the same filter name.
Hi @bvkimball , thank you for filing this FR with a great explanation! If I'm understanding it correctly, the proposal covers two aspects:
A way of passing extra variables to policy rules at runtime
A way of conditionally enabling/disabling some rules (on multiple models)
# 1 is similar to #1402. We can probably start by allowing the args() construct at the client level and then extend it to the query level for better flexibility. The latter will involve extending PrismaClient's current TS interface, but we're already doing it in V2 anyway 😄.
# 2 may be related to another thing that I've been thinking about for a while. Let me try to explain it here.
The current way policies are modeled in ZenStack is probably not good enough for modeling applications with multiple "sides". For example, an EC app can have a storefront "side" and a fulfillment "side". Authoring their rather different authorization rules in a "flat" way can be quite cumbersome and hard to maintain. So maybe we should introduce something like "profile" to segregate different sets of rules. (Please ignore the syntax, as it's just for showing the idea).
Is your feature request related to a problem? Please describe.
Sometimes i want baked in logic like soft delete mechanism into my model access policy. But sometimes the user/client can still access the data but only in implicit circumstances. Most of this could be implemented through the access policy and passing the parameter to the auth() but then you would need to create a new enhanced client. i believe you might want to enable/disable the access at the transaction level.
To rephrase, sometimes a single user of elevated "role" wants to view the application data the same as other users but by toggling an "flag" they can now include rows previously excluded (ie. archived, deleted)
Describe the solution you'd like
This could then be used as such:
Describe alternatives you've considered
Now some the examples above are contrived and arguably pointless, for example the
publishedBetween
could/should just be written in the where clause and this layer of abstraction is complicated. I agree, the example was to illustrate the concept.The real benefit here is for complex use-cases like effectiveDated/Versioned/Temporal models and "version" control, where a filter enabled at the top level will be enabled for relations that invoke the same filter name.
Then query the tree -->
The text was updated successfully, but these errors were encountered: