The aim was to produce a feature known as custom fields within the Issue Tracker component. This change was to be incorporated within the combined (Joomla 2.5/ 3.x branch) which at the time was the release 1.5 branch. This is a 1.6 feature.
The requirement is to be enable the addition of additional informational fields in the Issues details.
-
These additional fields need to be of different forms such as a drop down, radio, integer, link, URL, text fields etc.
-
These fields are to be populated upon the edit of the issue and stored within the database 'linked' to the specific issue and visible and editable from the front and back ends of the site.
There are two possible ways in which this could have been addressed. The first would be to add additional 'customisable' fields within the issue itself.
The site administrator could then tailor these fields themselves. However the downside of this is not knowing how many fields to provide and the specific field types required. It is almost certain that if one were to provide say 4 customisable text fields, someone would want five etc. This is one of the reasons why this is probably not the way to go!
A better and more extensible solution is to create a single extra table column and store all of the customisable fields within this one 'column' in JSON format.
This is the preferred solution and the one chosen to implement.
There are two additional tables required. The first is the 'custom field' table where the additional fields criteria are specified.
This includes such criteria as:
-
field name, field type (i.e. Drop down, Radio, text etc.). The default value the field is to take if not specified. (Null would be acceptable).
-
The required optional values if it were a check box or a option list. i.e.. "apple, pear, banana"
-
The tool tip text to aid the person entering the details.
-
The name of the group to which the custom field applies. (See below).
-
Validation rules that might apply to the field?
-
Published state of the field (whether to show it or not!)
-
Access rules that might apply to the field. (Who to show it to.)
The second table is the 'field group' table, which contains the details of the various 'custom groups' to which a 'custom field' would apply.
-
A custom group applies to a 'project', and potentially a project could have multiple custom groups. The initial implementation will be for a single custom group per project. Sub-projects would inherit the 'custom groups' of the parent.
-
A custom field would have a relative position (ordering column) within a custom group which would be used to determine display order.
Each of these tables has their own controllers, models and views (list and singular) on the back end for the definition and modification of the field and the field group.
The issue class method has changes to the 'save' and 'get' method to handle the new 'custom field column'. This applies to the front end and back end methods.
The projects and issues table have an additional field adding to provide linkage to the custom field and custom field group.
The back end project list display is changed to display the 'custom group(s)'. Front end possibly project list probably doesn't need changing.
The front and back end Issue list display are in the initial implementation unchanged with the custom fields only being shown in the single item views,. This may or may not be a possible future enhancement to the feature? [It would require breaking out the JSON column to extract the required 'custom field' to add to the list display.]
New text strings are created to handle the additional table fields and form display fields.
The displays have been modified to enable the display of the 'custom group' fields. There again are two ways of achieving this:
-
The first would be to let the site administrator define a 'template override' which would enable them to code where they wanted the field(s) to be displayed.
-
The second would be to provide an additional parameter on the 'custom group' definition to enable them to specify 'after' which field, the custom group should be displayed. This is not as 'customisable' as the template override option, but it does not prevent a site administrator using the template override option. This is the method implemented although the 'ordering column is used to define the order in which the various fields are displayed within a group, rather than provide a new option..
The issue display effectively has a number of 'visible blocks'. i.e. Summary (Title) and Description, a Progress block, and a Resolution block. The custom group effectively becomes an addition display block.
The former 'product details' request on the front end form has been migrated to make use of the custom fields feature, thus enabling the actual usage to be more easily tested and controlled going forward, as well as removing some unnecessary duplication of coding.
There are changes to add additional field(s) added to the issue and project tables to accommodate these Custom Field tables. The issues table accepts one additional field named 'custom_fields' and the projects table has an additional field named 'customFieldsGroup'.
The display of the custom field types makes a call to the a javascript routine which controls the fields shown upon the screen. Some of the field types have their own unique display of fields, others are adaptable with the ability to add additional criteria. Examples of the latter are the 'select', 'multi-select and 'radio button' field types where a list of possible options can be created. These are added by javascript which runs in the client browser.
Also implemented is the use of AJAX calls within the Issue display in the back end and the 'Raise an Issue form' in the front end which is invoked when the associated Project is selected by the raiser/editor and/or changed from that which is currently defined or is the default.