Why is Mendix inconsistent with its security access between role-based homepages and navigation items?
0
I can't wrap my head around the fact that I'm getting entity-access related errors when giving access to a page via role-based homepages versus the same access to that page via a regular menu item (in the list below role-based homepages). To provide some application context: Default homepage: Microflow to ProjectOverview ("NavigateToProjectOverview") Role-based homepage for role in question: not set, fallback to Default homepage Menu item (one of them): Projects (via microflow "NavigateToProjectOverview") This set-up provides no errors. On the page is a column the userrole in question has no access to. Instead of providing an error, the column is simply empty. When signing in, the user is automatically navigated to this ProjectOverview and can also navigate to this page via the menu. However(!), when setting a role-based homepage for said user role via the exact same microflow, loads of errors pop-up, writing there is no read-access to associations and attributes. Even when toggling entity-access on the microflow in the no-role-based situation, there is no error. Only when applying a role-based homepage. When setting up a role-based homepage, I'm getting errors for entities the user hasn't had access to for over a year, yet Mendix Studio never complained, as well as provided the user access to access-granted data without a problem. The issue is solely related to role-based homepages. I'm honestly unable to understand the difference, but the errors are causing a lot of (seemingly unnecessary) headache. Why do these errors occur and how do I eliminate them without providing entity access, removing columns from datagrids or applying visibility, while ensuring the column remains and the value is not provided to the user? At this point, my most reasonable solution would be not to use any role-based homepages and have a single microflow as the default homepage, using a decision based on the userrole, to navigate to the applicable homepage. Seems unlogical, but this bypasses the errors. I've tested this issue on both 9.24.36 and 10.24.1 and the results are identical.