[Feature Request] Encapsulation and Reusability of Permission Rules in ZModel

[alex-zwingli]

Currently, when defining permissions in ZModel, it is challenging to encapsulate and reuse permission conditions. For example, repeating complex permission conditions like auth().memberships?[permissions?[resource == currentModel() && action == currentOperation()]] across models or operations can lead to redundancy and reduced maintainability. Additionally, there is no straightforward way to ensure operations like create, update, and delete are allowed only when read is permitted.

1. Introduce a "function-like" construct in ZModel, such as rule, to encapsulate reusable permission conditions. For example:

   rule hasResourceActionPermission() {
     auth().memberships?[permissions?[resource == currentModel() && action == currentOperation()]]
   }
   

   This would allow defining reusable rules that can be called across models and operations.

2. Support parameters for rules to make them flexible and applicable to specific model types or conditions. For example:

   rule hasPermissionForAction(action) {
     auth().memberships?[permissions?[resource == currentModel() && action == action]]
   }
   
   

3. Allow rules to ensure granular permissions for operations (e.g., create, update, delete) while enforcing dependencies between them, such as requiring read to be allowed.

Alternatives considered
A current workaround is to define permissions as if read is allowed and then use @@deny with the inverse policy of read to deny actions when read is not permitted. However, this approach is not intuitive and can become cumbersome in complex models.

Additional context
This feature would significantly improve maintainability, reduce redundancy, and simplify permission management in ZModel. For example, using rules like the one below would enable concise and reusable permission logic:

@@allow('create,update,delete', check(self(), 'read') && hasResourceActionPermission())