As mentioned by Jermaine it is not recommended to modify the Administration module (Account entity for example) because your changes might be overridden when you update the module. And that applies to all App Store modules.
Having that said, you are now left with the options you present above:
To answer the “Account or User entity?” question: I have found that it is recommended to extend the Account entity instead of the User entity because some App Store modules (and reusable modules from other projects that you work on) might rely on the Account entity (and the administration module) which means that you will have to modify them every time you add or import one to your project that extends User directly. It will also enable you to make use of the pages and microflows included in the Administration module without having to modify much; however, I did not try to extend user directly before, therefore I cannot tell you much about the consequences of going down that path.
You need to answer 2 simple questions before you can decide which approach is better to extend the account entity, and those are:
If the answer to both questions is “Yes”, then the best approach from my experience is to create a specialization from Account which will include your additional attributes; however, if the answer to either of the two questions is “No”, then the best approach from my experience is to create a specialization from Account first (because you might want to add attributes that answer “Yes” to both of the questions above in the future) and to then create another entity that relates to that new specialization entity through a 1-1 association, and that entity should be the one including your new attributes. Because those attributes are either:
You might want to consider additional approaches depending on the specifics of your requirements. You can, for example, create two different entities that are specializations of Account, because you have two completely different groups of user accounts where no account could switch from one group to the other, and where the attributes required for each group is completely different. And so on.
NOTE: I did not clearly get your question in point #3, so please reply to this answer if what I’ve mentioned above does not address all your concerns; however, if you mean to say that you want to create an entity that is a specialization of Account and then to link that entity to Account through an association then that is a BIG “NO”. I’ve heard of projects where the developers have done something similar and in my opinion, it is a huge mistake.
Hello,
Having gone through some of the learnings, I believe they will state that the one best practice involves making an entity and then a generalization of Account.
Now personally I would do it the same way. For security reasons (no direct access to account entity or associations) and because Administration is considered an “App Store module” in Mendix.
Updating modules*
For updating modules you usually overwrite the old one and you will lose your changes. Now I have not had a case with Administration in the past. To me Administration is like a “java library item” and usually you do not edit libraries unless absolutely necessary (knowing that updating it will lose your changes).