It has indeed something to do with the grantable roles.
Without XPath
All Tenants records will be retrieved
With Xpath on list
With Xpath to Userrole, the grantable roles/can manage users with.. will be checked and filters out the tenants with a UserRole you aren't allowed to manage
DS microflow, with XPath in retrieve
Since by default security is bypassed in a microflow, behavior is like no XPath.
BUT
Looks like your TenantUser is used as a actor in your business process.
If so, I do advice to change your datamodel and security.
A User != A Person in your process.
A Person in your process can have a User account.
Just like you can have an passport, but you aren't the passport yourself.
give me a call when you need more on this ;-)
Hi Jason,
Note that Mendix treats xPaths on System.User (and specialisations) differently from other xPath constraints. According to Mendix this is working as designed, I disagree =)
Here is what might be causing this (from a ticket I had with Mendix years ago):
So the setup is like this:
- An Administrator can only create a TenantAdministrator (the Administrator can not do any Tenant specific activities or view Tenant data other than which tenants exist and manange TenantAdministrators)
- A TenantAdministrator is a role that should create accounts (users) for their own organization (tenant), in Project Security the user management for TenantAdministrator is set to User and TenantAdmin
- On the TenantUser (specialisation of System.User) the additional entity access is applied via xPath constraints, a TenantAdministrator should only be able to view and edit TenantUsers that are related to his Tenant organization.
This entity access xPath is ignored by the Mendix runtime when:
- Showing TenantUsers in an overview such as a DataGrid
- Retrieving TenantUsers via Microflow with Entity Access applied
The User management settings seems to supersede any xPath constraints on the System.User specialisations, even though they are more strict. The documentation and the Mendix evaluation guide suggest out-of-the-box support for Multi-tenant applications, but this creates a security issue, because data is accessible and editable when the security model defines otherwise.
So basically your Project Security (User management) will be "added" with the xPath constraints on the specialisation TenantUser. Not sure if that is also your issue in this instance, just wanted to share to make you aware of this behaviour.
(Normal behaviour would be that the security of the specialisation is applied and the security of the generalisation is ignored for the specialisations)
add a DS with a SUB that retrieves over tenant and role.