zenstackhq / zenstack

Fullstack TypeScript toolkit that enhances Prisma ORM with flexible Authorization layer for RBAC/ABAC/PBAC/ReBAC, offering auto-generated type-safe APIs and frontend hooks.
https://zenstack.dev
MIT License
2.05k stars 88 forks source link

[Feature Request] Separate files for model-level policies or validation #1077

Open nwidynski opened 7 months ago

nwidynski commented 7 months ago

Is your feature request related to a problem? Please describe. When developing complex access policies or validation a single zmodel can quickly get very chaotic.

Describe the solution you'd like A way to put model-level access policies and validation in a separate file or abstract model.

Describe alternatives you've considered We tried creating abstract models, which contain the model-level policies, but for Zenstack to recognize the fields we would have to extend a common base model, which it then complains is extended from multiple times.

abstract model CounterSchema {
  name String
  value Int
}

//! If we don't extend CounterSchema here, Zenstack doesn't recognize "value"
abstract model CounterCreate extends CounterSchema {
  @@allow("create", value >= 0)
}

//! If we don't extend CounterSchema here, Zenstack doesn't recognize "name"
abstract model CounterRead extends CounterSchema {
  @@allow("read", name == "It should be readable")
}

//! This fails compilation because CounterSchema is extended twice
model Counter extends CounterCreate, CounterRead {
  id String @id
}
jiashengguo commented 7 months ago

we would have to extend a common base model, which it then complains is extended from multiple times.

Would you please give us an example for this?

ymc9 commented 7 months ago

Maybe something like "partial models" can mitigate this problem? Like:

model Post {
  id Int @id
  title String
}

model Post {
  @@allow(...)
}

The two Post models can reside in different zmodel files and are merged during compilation.

nwidynski commented 7 months ago

we would have to extend a common base model, which it then complains is extended from multiple times.

Would you please give us an example for this?

I updated the description.

nwidynski commented 7 months ago

Maybe something like "partial models" can mitigate this problem? Like:

model Post {
  id Int @id
  title String
}

model Post {
  @@allow(...)
}

The two Post models can reside in different zmodel files and are merged during compilation.

Is this something that is working already? I'm asking because there is nothing in the docs about this.

ymc9 commented 7 months ago

Maybe something like "partial models" can mitigate this problem? Like:


model Post {

  id Int @id

  title String

}

model Post {

  @@allow(...)

}

The two Post models can reside in different zmodel files and are merged during compilation.

Is this something that is working already? I'm asking because there is nothing in the docs about this.

No, it's just a proposal😄. Sorry for causing confusion.

nwidynski commented 7 months ago

Maybe something like "partial models" can mitigate this problem? Like:

model Post {

id Int @id

title String

}

model Post {

@@Allow(...)

}

The two Post models can reside in different zmodel files and are merged during compilation.

Is this something that is working already? I'm asking because there is nothing in the docs about this.

No, it's just a proposal😄. Sorry for causing confusion.

Thought so 😄 . But yeah, a partial merge during compilation would be much appreciated.

ymc9 commented 7 months ago

Got it. I've put it into V2 milestone and will continue prioritize.