Understanding The Backlog App

The Backlog App enhances backlog management on Scrum boards by enabling filtering of issues based on specific custom field values. This section details the internal workings of the App.

Detailed app workflow

Step 1: Selecting a Custom Field in the User Input Selection Box

• Instructions:

• In the user input selection box, choose the desired custom field from the dropdown menu.

• The App uses the Jira Data Center REST API to populate this dropdown with available custom fields.

• When a custom field is selected, the plugin makes a POST request to save the current board state. This includes storing the selected custom field, along with the user key and board ID, as a unique entry in the database table.

• Explanation:
  By leveraging the Jira Data Center REST API, the plugin dynamically retrieves and displays a list of all custom fields available within your Jira instance. This ensures that any changes made to custom fields, such as adding or modifying them, are automatically reflected in the plugin's selection box upon refresh.
  

  

Step 2: Displaying Custom Field Values Using the Multi-Selector

• Instructions:

• After selecting the custom field from the dropdown, a new multi-selector interface will appear.

• This multi-selector displays a list of custom field values along with the number of issues associated with each value.

• The App retrieves the list of values and issue counts through a custom API call designed to fetch this data.

• Explanation
  The custom field API operates on the backend by fetching issues in batches of 500 using a JQL query. This query includes parameters for projects on the board and filters for issues where the selected field is not empty. As the API iterates through all the fetched issues, it constructs a map of custom field values corresponding to the issues. This map is then returned as the API response.
  

  

Step 3: Selecting Custom Field Values

• Instructions:

• For each value selected, the plugin makes a custom API call to retrieve issues containing that specific value.

• The retrieved issues are then displayed according to the selected values.

• A PUT request is also made to update the board state in the database, storing the current selections of the custom field values.

• Explanation:
  "Upon selecting a custom field value, a custom API call is made to fetch issues containing that value. The backend retrieves issues in batches of 500 and returns a list of these issues. This list is then passed to the pre-filter function, which is targeted at the data.json API, to perform the issue filtering on the frontend."
  

  

Step 3: Toggling the Not Equals checkbox

• Instructions:

• If the "Not Equals" toggle is enabled, issues that do not contain the selected values will be fetched.

• For each selection or toggle adjustment, a custom API call is made to retrieve the relevant issues based on the criteria set.

• The retrieved issues are then displayed according to the selected values.

• A PUT request is also made to update the board state in the database, storing the Not Equals Parameter.

• Explanation:
  "Upon selecting a custom field value, a custom API call is made to fetch issues do not containing that value. The backend retrieves issues in batches of 500 and returns a list of these issues. This list is then passed to the pre-filter function, which is targeted at the data.json API, to perform the issue filtering on the frontend."
  

  

Step 4: Reverting to Previous State

• Instructions:

  • If you wish to discard the current filtering and revert to the previous board state, click the cross icon .

  • This action triggers a DELETE API call, removing the current filter settings from the database and resetting the board to its condition before filtering.

• Explanation:
  Clicking the cross icon provides a quick way to clear all applied filters and return the board to its unfiltered state. This feature is useful for users who wish to undo their filtering changes and start fresh.

  The DELETE API call ensures that any temporary filter settings are removed from the database, thereby restoring the board to its previous configuration. This maintains consistency and allows users to easily revert to their original view without manually adjusting or reconfiguring the board.