[13]Decoupling the user system from Joomla

[Hackwar]

1. Introduction
1.1. Scope
This document should describe a way to decouple the user system completely from the rest of Joomla, making it exchangeable and easily extendable.
1.2. Objective of the document
This document is aimed at providing a basis for a discussion about a way to decouple the user system from the rest of Joomla.
1.3. General remarks
1.4. Definitions
1.5. License
GNU GPL
2. What is the current issue?
Joomla currently provides the possibility to authenticate against an outside source, which allows users into the system, that are not saved in the Joomla! #__users table. This could potentially create problems when those „temporary“ users create articles, postings in forums or similar, user-bound content entries, since the #__users table does not have the necessary informations for these users connections.
3. What are the proposed improvements?
The idea is to wrap all informations of the user in a class. This is already partially done in JUser, but the extent of it could be improved. This in the end allows to switch the complete user system from the Joomla system with the #__users table and maybe the phpGACL authorization system, to something entirely different, maybe even using a different Joomla installation to use the same userbase. Another possibility would be to switch to a file based user system, saving each user in a different file.
Furthermore, the way the user data is saved, should be changed and easily made extendable. How this will be possible, is described further down in the „Technical realisation“.
4. Technical realisation
The implementation of the JUser class should be pretty straight forward, the most work will have to be done with the other extensions like com_content to prevent using the #__users table and joining onto it. So far, com_content is almost the only component that does this joining in the frontend and we can easily prevent it. We already have the author_alias field in #__content, which we can easily use and auto-fill with the username of the author if no other value is given. That way we save a join on the #__users table and maybe even get some more performance out of the system. This has the disadvantage of a username or name change not dribbling down the chain into the articles automatically.
The other component in the frontend, which uses #__users is com_weblinks, which does this to sent out mails about a new weblink submission. With a class JUsers, which can query the userbase on different criteria, this could be ommited.
Since we want to make the userdata more flexible, the informations should be split in two. On the one side, the parameters like the default editor and on the other side the informations like adress and other contact details. These informations should then be available through get/set functions for the informations and getParameter/setParameter for the parameters. They are saved in seperate fields in the #__users table as serialized objects, which means we would have to add a text field like „informations“ in #__users. There is already a field named „params“.
To populate these fields, JParameter is used, which reads a global user.xml. This XML file holds a layout of parameters made by the user or an extension through the Configuration-Manager. For more details, please take a look at the according whitepaper. For the rendering of these parameters, a component like com_user could use a rendering layout, which could divide the different user settings by groups into screens like in global configuration or display them in different tables.
5. Possible uses
This would bring the long-asked-for extendable user informations and make all seperate user tables to store configurational data (which link against the #__users table) obsolete.
6. Effects on...
6.1. Users
There is no negative effect to be expected on the user.
6.2. Effects on 3P extensions
The system should be 100% backwards compatible and pose no problem for third party extensions to adapt to the new scheme. This means, that there is no negative effect to be expected on 3P extensions.
6.3. Effects on Performance
There should be no negative effect on the performance.

juser_0_1_hannes.zip