Table of Contents
Custom Fields were added to Issue Tracker to permit the adding of unique fields for an installation and in this way to extend the information captured and displayed to users.
It is highly likely that site customisation will involve the adding of some custom fields to the component. The definition of custom fields is currently covered in the user guide, so will not be repeated in this document. The interested reader is requested to consult that document for the details,
Custom fields are slightly different from the normal fields in that their display name is composed of a string containing a unique identifier. The text displayed is defined in the definition of the custom field itself, and thus there are no 'strings' in the language file to be found or modified..
All of the custom fields are stored within a single field in the database issues table in JSON format.
The definition of each custom field 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 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'.
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.
Changes to the display of specific custom fields is possible but is not for the faint hearted as it involves changes to the Ajax called routine in the controller. It is currently beyond the scope of this document to deal with these types of changes.