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

[nwidynski]

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]

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]

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]

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]

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]

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]

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]

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

[aladinelkhalil]

@nwidynski @ymc9
Brainstorming another approach on the same note; to create a new keyword "permissions" or "config" or similar that define permissions for a specific existing model. Example:

model Post {
  id Int @id
  title String
}

config Post {
  title @length(min: 2, message: "Title must be at least two characters")

  @@allow(...)
}

Especially with the already existing ability to divide schemas inte several files, this could be divided into zmodel.schema and permissions.schema