test

[jiashengguo]

Is it possible to have this feature supported in the near future? :sweat_smile:

As an alternative, you may want to take a look at a Prisma extension library ZenStack that we are currently working on. The schema is fully compatible with Prisma Schema, and you can have syntactic custom attributes as below:

model User {
    id        String @id
    email     String @email
    password  String @password @omit
    // everyone can signup, and user profile is also publicly readable
    @@allow('create,read', true)
}

attribute @email()

attribute @password(saltLength: Int?, salt: String?)

attribute @omit()

attribute @@allow(_ operation: String, _ condition: Boolean)

Moreover, It would still work with all the existing generators of Prisma using /// comment: solution. If you're interested, I have also written a post about the implementation details, which you may find helpful.

[jiashengguo]

Any update on this?

As an alternative, you may want to take a look at a Prisma extension library ZenStack that we are currently working on. It has a built-in access control layer. So in order to get a soft delete query for a model, all you need is to add the below access control policy in the schema file. Then the soft delete will just work automatically.

model Post {
  ...
  deleted Boolean @default(false) @omit
  @@deny(‘read’, deleted)
  ...
}

We have tested the cases mentioned in this issue, like AND, OR, every, some, not, etc. But if you meet any case that we missed, we would appreciate it if you could create an issue on GitHub or directly throw it to our Discord

I also wrote a blog post for it. Check it out if you are interested.

[jiashengguo]

The Prisma extension library ZenStack we are building uses a declarative way in the schema to handle the RLS. To achieve what Postgres can do in the original problem, you could simply add an allow policy rule in the schema as below:

model Post {
    id Int @id() @default(autoincrement())
    title String
    owner User @relation(fields: [ownerId], references: [id], onDelete: Cascade)
    ownerId String

    // Only the owner has full access. 
    // auth() returns current user
    @@allow('all', auth() == author)
}

And then create a wrapper of Prisma client using withPresets provided by ZenStack which adds a transparent proxy on Prisma guarded by the access policy defined in the schema above

// the standard Prisma client
const prisma = new PrismaClient();

app.get('/posts', (req, res) => {
  const db = withPresets(prisma, { user: getSessionUser(req) });
  res.json(await db.post.findMany());
})

The above API only returns the data filtered by ownerId = current_user_id.

Of course, you could have more flexible fine-grained control over it using Access Policy of ZenStack, below is a tutorial post for a more complicated case:

How to build a collaborative SaaS product using Next.js and ZenStack's access control policy

We would really appreciate it if you could share your opinions by commenting or joining our Discord to help us make ZenStack the right thing to solve your problems.