In most of my projects I need some special attributes for accounts like:
Currently the account object has no defined doctrine inheritance type like single_table or join table.
As most times not so many fields have to be added I would opt for a single table inheritance for speed reasons!
There was also a RFC in the typo3 gerrit, but the discussion stopped and so it was not merged.
For completeness, here are the old issue - https://forge.typo3.org/issues/41297 - and the change - https://review.typo3.org/16232.
It boiled down to:
Hi,
this is a delicate one because it might introduce a tight coupling that can lead to conflicts if multiple packages try to extend the account model. I’m not sure what you mean by “synckeys”, but I think all of the above could be dealt with without having to extend Account.
For example the “user needs to change password”: Why not just store that in a separate table? Or even more flexible: Whenever the password is changed store the account id & timestamp so that you can reason about it with more knowledge (e.g. the password was changed > 6 months ago -> set role “Some.Package:ExpiredPassword” that has only limited privileges. the password was changed > x times within y days -> alert). The nice thing: This could also be done asynchronously, so without penalty to your application’s performance.
A lot of user specific information can also be stored in the custom User model that is part of the package’s domain. But sometimes the line is blurry.
What I would like to see though is an AccountInterface in order to make it easier to work with unpersisted accounts (e.g. if you want to use some kind of Single Sign-On). It would also allow for accounts being persisted in a completely different storage.
mhmm ok, we will try to solve that somehow with AOP.
My suggestion/question from 8 years ago is still valid IMO and I can only warn you to use AOP to “fix” something that is like this for a reason