During our development of our Time sheet component we looked very closely at the use of specific component user tables. These are tables that are specific to a component, which are/can be very useful when there is a requirement to associate some specific criteria to one or more users. i.e We might wish to enable email sending only to specific users. This could be achieved with the use of Joomla ACL controls but often this can be a little bit overkill especially when there are a number of different combinations involved. In these situations the number of ACL groups required could/would quickly get out of hand and require a lot more overhead in determining the result if user actions in the component. Such user tables are often automatically populated by a system plugin that would automatically add any newly registered Joomla users to the component user table and also maintain any changes that the user might make to their profile such as username or email address between the Joomla user table and the component user table.
One other use for a specific component user table would be where there is a requirement for specific ‘unregistered’ users. An example might be where the component was collecting details of users who requested information upon a specific topic by filling in a form upon the site front end, and at some later stage an administrator might process such requests from the details recorded in the component user table.
Generally component user tables work well in practice but there is one large downside, which is that there is (in all of the uses we have seen), an explicit assumption that all Joomla users will or are required to make use of the Joomla component, which is not necessarily true. A Joomla web site will probably have a number (often in the hundreds if not thousands) of users and if the site has a specific component installed that is used for example, by internal staff only, there is no need to have additional entries in the component users table for the non-staff members. In the case of our Timesheet component only certain of the site users would make use of the component so there is no need to have an entry in the component user table for every single one of the Joomla users.
This has resulted in our implementing a change to how Joomla users are integrated into the component user table. The former mechanism of having automatic user table update by the use of the system plugin was obviously not desirable,however we did want to synchronise any updates (and deletions). Thus we have a need to introduce an optional parameter to the system plugin which will control whether new Joomla users are automatically added to the component user table.
With this in mind we have modified a few of our components, and are in the process of modifying a few others, so that the automatic addition of Joomla users to the component users table is a system plugin option. This change is relatively trivial, but there is an additional change required, which is to provide a mechanism so that users can manually added to the component users table by a site administrator when required, such as when new staff join the company..
The first component to use these mechanisms was our Timesheet component and we have now also added our Rialto (Classified Ads) component, Obviously in the first of these we are only interested in providing the ability to create timesheets to our internal staff. In the later component we may only have a select sub group of users who we may want to be able to create/manage their classified advertisements. We will also add that, yes we do also include the ability in the components to use Joomla ACL rules but this alone would not address the number of entries in the component users table and could well make the administration of ACL groups a lot more complex as mentioned earlier.
There is some additional code required but the benefits include a smaller component users table, with much clearer administrative visibility and control over who is using the specific component. It also provides the ability to have a simple test upon whether the register user in the front end has an entry in our component user table to control what specific front end views they may be presented with.