The current implementation assumes that generated also implies immutable , but not non-deletable (and older version did assume non-deletable). In this issue we want to consider changing this behavior, so the two annotations work independently.
This combination is not used in Facebase, but in RBK the way the annotation is written seems to assume that generated implies immutable and non-deletable.
This was a blocker in CFDE since we want to disable "create" through chaise but allow "edit". Hence we decided to add a special false value for all the ACL annotations. false means that the inheritance should be ignored and the value should be used without needing to consult with other annotations. For instance if immutable=false is defined on a table, we shouldn't look for schema's ACLs annotation or the generated annotation on the table.
I should mention that the ACL annotations don't "grant" permission. They are mainly used to "take away" a permission, and the special false value is just to block the interpretation of inherited annotations. So even if you set immutable=false on a table, we will consult with the real model rights to figure out if the client has the proper privileges or not.
The current implementation assumes that
generatedalso impliesimmutable, but notnon-deletable(and older version did assumenon-deletable). In this issue we want to consider changing this behavior, so the two annotations work independently.This combination is not used in Facebase, but in RBK the way the annotation is written seems to assume that generated implies immutable and non-deletable.
This was a blocker in CFDE since we want to disable "create" through chaise but allow "edit". Hence we decided to add a special
falsevalue for all the ACL annotations.falsemeans that the inheritance should be ignored and the value should be used without needing to consult with other annotations. For instance ifimmutable=falseis defined on a table, we shouldn't look for schema's ACLs annotation or the generated annotation on the table.I should mention that the ACL annotations don't "grant" permission. They are mainly used to "take away" a permission, and the special
falsevalue is just to block the interpretation of inherited annotations. So even if you setimmutable=falseon a table, we will consult with the real model rights to figure out if the client has the proper privileges or not.