Annoying to OCD patients and perfectionists and confusing for anyone starting with Mendix are the entities User and Account:
What is wrong here? Well *1, for starters, the entity User does not contain attributes of a user, but attributes of a “User Account” being the access information you get when you sign up for any service, among which username&password *2.
The entity Account, on the other hand, contains attributes of a real-life person, having a name and an email address. The Account is defined as a specialization of User. It is the only specialization, which is a code-smell and its attributes Fullname and Email suggest that this is about a person *3. But a person IS not an account (specialization) but HAS an account *4 (association).
The IsLocalUser-boolean defines if this account is or is not a local user. Same as the other boolean-attributes of entity User*5 it should be located in the entity currently defined as User. Also, the boolean's names can be more clear when prefixed with ‘Is' *6.
Then the non-persistent AccountPasswordData. It is associated with Account although it is acting on attribute Password of entity User *7.
The Association between User and UserRole is named UserRoles, which is confusing when creating a XPath because it differs from the rest of the Mendix apps. Stick to the naming conventions and rename it to UserAccount_UserRole *8
None of the attributes, not even the entities themselves (User, Account and Userrole) have any documentation *9.
*1 Rename entity User to UserAccount
*2 Rename User's attribute Name to Username
*3 Rename Account to Person
*4 Give administration-Person 1-* relation with UserAccount (now User)
*5 Move the attribute UserAccountType (now IsLocalUser) to UserAccount (now User)
*6 Rename booleans Blocked, Active, IsAnonymous and WebserviceUser to IsBlocked, IsActive, IsAnonymousAccount and IsWebserviceAccount
*7 Associate AccountPasswordData to UserAccount (now User)
*8 Rename UserRoles to UserAccount_UserRole
*9 Use the Documentation field on the entities and on the attributes to describe what they mean.
As a result, we would end up with this domain model with entities Account, UserRole and AccountPasswordData in module System, and entity Person in module Administration:
(Edited since Rom is correct: Account_Userrole is now *-*)
Module Administration now maintains the data of each person having access to the application and the module System is all about the accounts. Naming standards and best practices are upheld. And most important: the handling of persons, accounts, and roles has become plain and simple.
10 Rename association HttpHeaders to HttpHeader_HttpMessage
I now created and uploaded the Appstore app SystemManagement as an alternative for the Appstore app Administration. You can check it out in the systemmanagement-sandbox. Please help me to improve it by sending feedback on it via the feedback button or leave a review in the Appstore.
Person should contain 0 attributes.
I totally agree. This is something which should really be fixed. For fresh mendix developers this is always causing some misunderstandings on how to use the two entities “System.User” and “Administration.Account” properly.
The suggested domain model really looks clean and should be integrated in the System module and we should get rid of the Administration Appstore Module.
Account_UserRole should be a reference set, but otherwise I completely agree!
In my opinion they don't need to add phone, date of birth and such to the ‘Person’ entity per se, the most important thing would be to stop inheriting user and to fix the associations and their naming