Introduced in version 2.6 (released August 2021)
Keep your attributes editable within data views, because if an access rule prohibits write access, your client will display it as non-editable – this way you are aware of the (correct) working of an access rule.
Why is it a security risk?
Whilst testing your application, it may be more difficult to spot if your security is managed the right way due to the fact that it may seem that a user has no access to an attribute (editability managed on the page: never) whilst the security is wide open in the domain model. Therefore it’s good practice to always set the editability of an attribute reference widget to default.
Non-compliant example
Compliant example
How to solve?
Set the editable value in the properties menu to Default.
In some cases, the attribute reference that is violated is part of an inherited editability. This is caused by setting a (e.g.) data view or list view to not-editable. As a consequence, all the nested widgets inherited the set editabilty. This is shown in the modeler as:
If the attribute widget without inheritance is set to never, the rule will give a violation. To fix this violation, go to the top level widget that causes the inherited editability, change it (temporarily) from no to yes. Go to the violated widget and set its editable value to default. If correct, change the editability of the top widget back to no.
