Creating a trigger is performed by clicking upon the 'NEW' icon button in the Trigger list display. This would then display the figure below, which has a few fields which need to be completed. These are the table upon which the trigger is to be placed, the type of trigger required (BEFORE or AFTER), the operation to be monitored (INSERT, UPDATE or DELETE), and whether the trigger should be applied immediately after being created.
The trigger created at the end of this stage would be based upon 'ALL' of the columns that are in the selected table.
If the 'Save' icon button is pressed then the display is changed and a few additional fields are now available. The first of these is the 'Columns' field which has to be completed. It is this field where one selects the specific columns within the table that are to be monitored. The fields are selected from the drop down list and there is also the 'All' option if one wishes to retain the previously generated trigger upon all of the table columns. If the 'ALL' option is selected then any other selected fields are ignored.
If the 'Save and Close' button is pressed the Trigger list display is shown and the 'columns' entry indicates '(array) All'. If the entry is edited then it is necessary to explicitly select the 'All from the columns drop down list as described above otherwise an error message indicating that the column must be specified is displayed..
Note | |
---|---|
By design it is not possible to edit the generated trigger text. |
After supplying the required columns when the save button is pressed the trigger text is regenerated with the new selection.
Note the entries in the 'columns' field when populated with desired values as shown in the figure below.
When saved the selected columns field would be shown in the Triggers List as indicated in the figure below.
The above is an example for a small selection of fields, which are stored in the table in JSON format.
Important | |
---|---|
The feature does not have any ability to incorporate the contents of any existing trigger upon the Issue Tracker database table. This restriction should not provide a problem for most systems. The reason is that the Issue Tracker component is controlled by ourselves and any other trigger that might exist upon the table are almost certainly a 'site modified' change, and thus not supportable by ourselves. |