Customization of Ticketing Template

When Jira Connector Application begins, the Ticketing Scheme Template files are created in template directory. You can get the latest Ticketing files from the GitHub Repository.

You can use the default Ticketing Scheme templates without any change.

In some cases, you can customize the ticketing template. Let's explore those cases below.

Customize PriorityMapping  

1. You can change the default levels, "Highest," "High," "Medium," and "Low," as per the priority configuration in your Jira Instance.
2. If you are Using Link-Unlink Ticketing Scheme the changes should be apply for both Parent Ticket and Related Ticket. 
   Ex. If your Jira instance has “Critical1”, ”Critical2”, ”Critical3”, ”Critical4” Severity levels then you must configure it in Your Ticketing Template for both Parent Ticket and Related Ticket. You cannot alter the 1-100 score range as this is the range followed for QDS scoring. Also You cannot alter the 0-1000 score range as this is the range followed for TrueRisk scoring
   1. When creating tickets, the Jira Connector can map the issue priority based on risk scores. The Jira Connector maps the issue priority by analyzing the QDS score,Vuln Severity and TruRisk Score
   2. HD profile - The Jira Connector maps the issue priority by analyzing the QDS score or Severity for detections and the TruRisk score for the Host. If risk scoring is not enabled in config.json, then the default Jira instance priority will set. You can set the priorities using severity level for related Ticket by replacing the 'matchWith' field value with the value provided for the 'severity' custom field.
   3. For WAS, CS-Image and CS-Container- The Jira Connector maps the issue priority by analyzing the Severity Level.

Customize Payload

1. Add the desired field name under custom field section and map it with the respective field name from the API response. For example, to add the field QG Host ID, the custom field section should have
   

   "QG Host ID": {

               "value":"${QG_HOSTID}",

               "customFieldId": ""

    }

   In the example - "QG Host ID" is the name of the field in your Jira instance and ${QG_HOSTID} is the field name from the API response.        
2. In case of Mandatory fields, with v1.3.2, we have added support to handle mandatory custom fields of type labeland select List (Single and multi- choice), Number Component System field, Paragraph, Read-Only, and Short text (plain text only). If your Jira Instance has a mandatory field, your ticketing scheme might fail then You need to set the Mandatory field on the ticketing scheme template.

   For example,
   "component": {
"value":"test",
"customFieldId": "customfield_10036"
}

   Where "component"  is the name of the mandatory field.

   "test" is the  value that is applied to all the tickets created by the Jira client.

   "customfield_10036" is the ID of the custom field.

3. In your Jira instance, if there are two custom fields with the same name but different field types, the Jira Client displays an error: "An exception occurred while trying to resolve custom field ID for module VMDR and fields [Custom Field Name]. Error- "Cannot proceed further until conflict is resolved". In case of such errors, you need to configure Custom field ID in Ticketing Scheme template for the custom field with the correct field type.

Configure the Custom field ID in the Ticketing Scheme Template as per the below example

                   "Impact": {
                   "value":"${vuln.impact}",
                   "customFieldId":"customfield_10009"
              }   

The cases described above require the addition of a custom field ID on the template. To obtain this custom field ID, follow these steps.

1. Navigate to project Settings > Fields >Actions > Edit Field> Custom Fields > search for a Custom Field
2. From the results, click Edit Details on a custom field.
3. The URL above shows the custom field ID. For example, id=10034.