Product SiteDocumentation Site

⁠5.5.2. Bug Actions

⁠

EVENT_REPORT_BUG_FORM (Execute)

This event allows plugins to do processing or display form elements on the Report Issue page. It is triggered immediately before the summary text field.
Any output here should be defining appropriate rows and columns for the surrounding <table> elements.

Parameters

  • <Integer>: Project ID
⁠

EVENT_REPORT_BUG_FORM_TOP (Execute)

This event allows plugins to do processing or display form elements at the top of the Report Issue page. It is triggered before any of the visible form elements have been created.
Any output here should be defining appropriate rows and columns for the surrounding <table> elements.

Parameters

  • <Integer>: Project ID
⁠

EVENT_REPORT_BUG_DATA (Chain)

This event allows plugins to perform pre-processing of the new bug data structure after being reported from the user, but before the data is saved to the database. At this point, the issue ID is not yet known, as the data has not yet been persisted.

Parameters

  • <Complex>: Bug data structure (see core/bug_api.php)

Return Value

  • <Complex>: Bug data structure
⁠

EVENT_REPORT_BUG_MODERATE_CHECK (First)

This event checks whether a new issue will require moderation.

Parameters

  • <Array>: Empty array (no parameters)

Return Value

  • <Boolean>: Return true if the issue will require moderation, false otherwise
⁠

EVENT_REPORT_BUG_MODERATE (First)

This event allows plugins to intercept submitted issues for moderation. The plugin will queue the issue data for moderation approval. If moderation is required, the issue is not created in the database until it is approved.

Parameters

  • <Array>: Issue data array from the request payload (command format)

Return Value

  • <Boolean>: Return true to indicate the issue was queued for moderation (prevents normal creation), false to allow normal processing
⁠

EVENT_REPORT_BUG (Execute)

This event allows plugins to perform post-processing of the bug data structure after being reported from the user and being saved to the database. At this point, the issue ID is actually known, and is passed as a second parameter.

Parameters

  • <Complex>: Bug data structure (see core/bug_api.php)
  • <Integer>: Bug ID
⁠

EVENT_UPDATE_BUG_FORM (Execute)

This event allows plugins to do processing or display form elements on the Update Issue page. It is triggered immediately before the summary text field.

Parameters

  • <Integer>: Bug ID
⁠

EVENT_UPDATE_BUG_FORM_TOP (Execute)

This event allows plugins to do processing or display form elements on the Update Issue page. It is triggered immediately before before any of the visible form elements have been created.

Parameters

  • <Integer>: Bug ID
⁠

EVENT_UPDATE_BUG_STATUS_FORM (Execute)

This event allows plugins to do processing or display form elements in the bug change status form. It is triggered immediately before the add bugnote fields.
Any output here should be defining appropriate rows and columns for the surrounding <table> elements.

Parameters

  • <Integer>: Bug ID
  • <Integer>: New Status
⁠

EVENT_UPDATE_BUG_SHOW_CUSTOM_FIELD (Default)

This event allows plugins to show a non-required custom field on the bug_change_status_page, when the bug/ticket is in a custom state (non-native). It is only possible to show fields, not to hide them trough the plugin.

Parameters

  • <Complex>: Bug data structure (see core/bug_api.php)
  • <Integer>: Customfield ID
⁠

EVENT_UPDATE_BUG_DATA (Chain)

This event allows plugins to perform pre-processing of the updated bug data structure after being modified by the user, but before being saved to the database.

Parameters

  • <Complex>: Updated bug data structure (see core/bug_api.php)
  • <Complex>: Original bug data structure (see core/bug_api.php)

Return Value

  • <Complex>: Updated bug data structure (see core/bug_api.php)
⁠

EVENT_UPDATE_BUG (Execute)

This event allows plugins to perform post-processing of the bug data structure after being updated.

Parameters

  • <Complex>: Original bug data structure (see core/bug_api.php)
  • <Complex>: Updated bug data structure (see core/bug_api.php)
⁠

EVENT_MOVE_BUG (Execute)

This event allows plugins to perform post-processing after an issue has been moved to another project. It is triggered after the issue and its attachments have been moved and after the optional move note is added.

Parameters

  • <Integer>: Issue ID
  • <Integer>: Source project ID
  • <Integer>: Target project ID
  • <Integer>: Move note ID, or 0 when no note was added
⁠

EVENT_BUG_ACTIONGROUP_FORM (Execute)

This event allows plugins to do processing or display form elements in the bug group action page form. It is triggered immediately after the standard fields, and before bugnote fields (if applicable).
Any output here should be defining appropriate rows and columns for the surrounding <table> elements.

Parameters

  • <Array>: Array of event data elements

Parameter array contents

The parameter array contains elements for these indexes:
  • 'action' => <String>: Action title (see bug_actiongroup.php)
  • 'bug_ids' => <Array>: Array of selected bug ids
  • 'multiple_projects' => <Boolean>: Flag if selected bug ids span multiple projects
  • 'has_bugnote' => <Boolean>: Flag if current group action form contains a bugnote input
Depending on the action, any of these indexes may appear:
  • 'custom_field_id' => <Integer>: If action is 'CUSTOM', contains the custom field id selected for update
⁠

EVENT_BUG_ACTION (Execute)

This event allows plugins to perform post-processing of group actions performed from the View Issues page. The event will get called for each bug ID that was part of the group action event.

Parameters

  • <String>: Action title (see bug_actiongroup.php)
  • <Integer>: Bug ID
⁠

EVENT_BUG_DELETED (Execute)

This event allows plugins to perform pre-processing of bug deletion actions. The actual deletion will occur after execution of the event, for compatibility reasons.

Parameters

  • <Integer>: Bug ID