Chapter 9. Sample Data

The following describes the supplied sample data and specific notes upon its usage.

[Note]Note

Sample data is only available provided the underlying Joomla database connection user has the database privilege to create database procedures. Release 1.4.2 (and above) will remove the icons from the control panel to handle this data if the database privileges have not been granted.

Loading Demonstration Data

As mentioned above, demonstration (or sample) data is provided for testing and investigating the implementation. In Joomla the component control panel provides an easy mechanism to enter (and remove) the sample data.

The sample data uses the early identifier (id) fields in the tables. Of particular note is the use of sample users which are using the Ids from 2 to 18.i In Joomla user ids usually (since 1.7) start from an ID of 42, with the Super User account normally be ID=42. Thus is usually reasonably safe to use the early IDs for our purpose. How ever since the Super User ID is so well known there are a few Joomla extensions that ‘improve’ security by re-assigning a Super User account to a different, sometimes random ID. If one of these components has been used on the Joomla site and the ‘new’ Super User ID falls within our sample data people range there is the potential for conflict.

NOTES:

  • Be careful when using the remove sample data icon since there are only simple checks that the data it is removing is ‘sample data’.

  • Joomla 2.5.4 introduced a randomisation of the created Super-User account identifier (id). This means that the Super User (admin) can have virtually any value and may well conflict with the loading of sample data, since the Id for the sample people added will clash. A work around has not been generated for this problem and the future of the sample data means that it may be removed from versions 1.3 and above.

Sample data is actually of two types. The first type is the supplied Roles, Statuses, Issue Types and Priorities that are used within the system. This data is used to populate the tables when the component is installed. This data is never removed except when the component is un-installed, or if/when a site administrator specifically removes it. Before removing these data items if is suggested that the settings of the ‘default’ options are studied and/or modified before proceeding.

There are also two pieces of data that should be mentioned and treated very carefully. There is a User known as ‘Anonymous’ created with an ID of 1 in the it_people table. This user is used as the default for issues saved from the front end of the site by a guest user. This default can be changed by the component option settings. The second data item is a project known as ‘Unspecified Project’. This is a default project used for people and issue assignment. Again this can be changed from the component options. Care should be taken if it is intended to remove these two piece of data.

The second type of sample data is that of ‘sample’ issues, projects and people. This is the sample data installed by the button on the Administrator Component Control Panel as described above.

There are a number of checks that the component performs when the request to load or remove the sample data is invoked. Of particular note is that if there exists an entry in the it_people table with an id between 2 to 18 inclusive, then the data will not be installed. On removal checks are also present to prevent sample data removal if any of the sample data has been changed to reference non-sample data or if the sample data is referred to by non-sample data.

[Note]Note

The sample data changed in Release 1.2.0 due to a change in the assignment of an issue which has to be to a ‘registered’ Joomla user. This change means that the sample data which was previous assigned to non-registered users would no longer work due to the table constraints. The sample issue sample are all therefore un-assigned.

Prior to release 1.2.0 the primary key of the it_people table was an id column based upon the id of the person in the Joomla users table. This meant that because the Joomla users ids’ started from around 42 (depending upon Joomla version) that the id column in the it_people table was also starting around the id of 42.

With release 1.2 of Issue Tracker, the value of the user id as used in the Joomla users table is now stored in the it_people table as a user_id, and the id column is an auto incrementing numeric.

One consequence of this is that if we do not start the numbering of the id column from a value higher that 20 (the highest id currently used by the people sample data) there would be id conflicts.

For that reason the starting value for the id in the it_people table is set at 31, leaving some scope for future data if required. For a new installation the entries will therefore start at 31. The Anonymous user will retain the id of 1 since that is hard coded in our installation script.

For an existing installation without issue tracker installed the new starting id of 31 will still work, except if the Super user has an id in this range, so we double check when we try to install the sample data people. Hopefully there will be no other users within the range. If there are then the sample data installation will fail gracefully. With a new Issue Tracker component install the auto increment value is set in the table creation. If an existing installation there may already be people in the it_people table but their id's will be higher than that of the super user.

Joomla 2.5.6 changed the possible values of the Super User id to a random valve, and it seems to have also at the same time set the auto increment value for that table to be higher than the given id. So any new users would automatically get higher user id values. So these should not get created in the lower range. The problem comes when the super user falls in our range and other users follow on sequentially. i.e. The random Super user id gets set to say 15, then l6, 17, 18 etc can be used by other registered users. This would mean we would have to keep track of which ids we assigned to out sample users so that we could remove them again. Very messy especially as we would have to change the identified_by field values in the it_issues table for that sample data. Could be done but is it worth it?

We are not aware of any other component that also uses sample data in this way, but you never know.

Checks are implemented to try and catch any situation where an attempt is made to remove the sample data where it is not installed and there are id’s in use within the sample data normal range. However it has not been possible to test for every possible end case, so care should be exercised when trying remove the sample data especially if it was not installed in the first place.