Entity Access on Attributes cause display errors

3
More of a discussion than a question, but why does Mendix throw a "No read access" error instead of warning if you restrict attributes in an entity for a role but give the role access to a page that has a mixture of restricted and non-restricted attributes? Currently I have to create another page to route to or define visibility restrictions on the page, if even possible (using datagrids is not a possible to restrict in this manner). In my past life with other tools, when I restricted the attributes, they just don't populate the values in the grids on the page instead of stopping the app from compiling and running (and creating new pages and workflows). Does anyone have an explanation why this is preferred rather than just not populating the attribute values?
asked
2 answers
3

The errors are given because otherwise the client might try to access an inaccessible attribute and that would result in a run-time security error.

However, the Modeler security check that checks whether attribute access is allowed takes a lot of time (sometimes more than all of the other checks combined) and does not cover all cases, so I would love to get rid of it entirely. Internally we also came up with the idea to not render widgets if you do not have access. Now that we have input widgets with built-in labels, I think it would nicely if we just hide a text box if you do not have access to an attribute. The only thing is that you might be surprised that a widget or column is suddenly gone, but that might be a small price to pay.

So yes, good idea and I have good hope that we can do this in the near future!

answered
0

Nolan,

The compilation error as you call it, can be circumvented by unchecking the check security box in the security settings. Be aware however that you'll need to take more care on setting the security without the help of checks by the modeler. Although you can now run the model, this setup will still require you to setup conditional visibility based on roles on the pages, else you'll get to see the errors for the fields referring to the permissions that will not allow to build the widget. So doesn't seem to be the greatest thing to setup in your model. I would agree that when permissions are not assigned the interpretation of the model could be to simply not render the widgets in stead of showing an error. Maybe the rationale is that the errors would provide a feedback mechanism that would otherwise not be possible. Also this checking forces the modeler to carefully think about security and enforce consistency. That being said I would also be able to live with the option that fields are not rendered if permissions on attributes are not set.

answered