There is a disconnect in Mendix when trying to go between System.User and Administration.Account objects. Currently, the recomended approach is to do a retrieve and fetch the Account object based on the System.User/Name attribute. This is annoying as it adds additional actions to microflows and makes some other retrieve actions not straight forward. The main issue here is that if you decide to use the built in "owner" and "changedBy" system member attributes in an entity there is no direct way of displaying the corresponding users Account information like Full Name or Email on a screen without having to perform multiple extra steps to fetch that information. If you did want to display this information alongside whatever entity is on screen, you have to either add additional dataviews to fetch this (which isn't recommended) or create additional NPE's to store this reference. This leads to these system member attributes being all but useless on the frontend, and the developer has to now manually add and update these as regular associations. Now developers are having to avoid the built in features of the platform due to limitations which only slows down development time and complicates their apps. You would think that displaying the users actual name over their username would be a basic and fundamental feature when showing something like "Created By: " or "Last Updated By: " but apparently Mendix either figured this wasn't something anyone would need or thought it was okay to require multiple additional steps to achieve this. Now that we are manually storing Administration.Account associations for these fields, we have issues when we need to try and do a retrieve against this entity using a System.User entity since there is no direct way to perform this either, requiring yet another additional retrieve step to fetch the corresponding Administration.Account object via the "Name" attribute.
I don't understand how you can't be using something beyond just System.User. Are people building apps where users don't have names or email addresses? These fields should then be added to the System.User entity if there is concern of apps now using the Administration.Account entity.
The core issue still remains here, there is no built in native support from Mendix to display attributes beyond just the username when using the built in system meber attributes due to their user structure, which to me is a fundamental issue that should not require the developers to custom implement logic in every single app to get around. I am tired of having a dozen plus of these "workarounds" for Mendix and want to start seeing them addressed so the platform can properly be utilized for what its advertised as being: Rapid Application Development
Not everybody uses the Administration.Account module. Or you could even have users scattered over various entities. So I don't. think it can be pinned on Account.
In your case, I'd suggest to create a view entity where you join Administration.Account on System.User. And I would join it on id instead of Name.
Yes, it's an extra step, but you would have clean microflows/pages. And better performance.