Jira Add-On Configuration

Owned by Ray Rarey
Last updated: Jul 11, 2023 by MobilityStream Team
5 min read

The Jira add-on allows an administrator to control some features that affect the add-on's behavior. Most configuration options are available from the add-on's Configuration screen.

Webhooks

This section of the Configuration screen allows an administrator to toggle which Jira events will trigger updates to real-time update exports. By default, only issue- and worklog-related events are enabled. Most administrators find that the default configuration meets their needs, but there are cases where you may want to enable other webhooks. For instance, if you have an export that should update when a sprint is closed, an administrator would enable the "Sprint Closed" webhook so that your export is updated when the sprint is closed. It is also possible to disable all webhooks if you need to quickly stop updates to all of your exports.

Toggle webhooks as necessary for your goals, and click the Save Configuration button to save your new selections. This change takes effect immediately for all exports.

Realtime-Enabled Projects

This section allows an administrator to define which projects' Jira events will trigger updates to real-time update exports. By default, every project is enabled. Administrators may find that some projects do not need to update exports, and disabling those projects here may provide a performance benefit. Jira events fired from issues in projects that are not enabled here, will be ignored. Note that this section and the Webhooks section work together; the add-on will only process enabled events on realtime-enabled projects. Users are still able to export issues from projects that are not enabled here, but changes to issues in those projects will not trigger real-time updates, even if the export itself is realtime-enabled.

Issue Export Limit

This section allows an administrator to set a limit on the number of issues that can be exported at one time. Since larger exports take more time and resources to generate and update, limiting the number of issues in the exports can help improve performance. The default limit is 1,000 in Jira Cloud. To allow an unlimited number of issues, set this value to -1. Any limit set here applies to all exports created by the add-on.

Additional Export Options

This section allows an administrator to expose additional data export options for users to select on the Export screen. If any options are enabled here, an "Additional Export Data" item will appear on the Export screen, giving the user the option to export additional data to other tables in the selected namespace. Currently there are 8 additional export options available, with 7 of these options being configurable by a Jira administrator.



Components, Issue Types, Projects, Users, and Versions will each perform a full export of their data into their respective tables in the selected namespace. In the case of Changelogs and Worklogs, only the data that relates to the issues present in the user's export will be exported into their respective tables.

The final export option available to users, Field Mapping, is not configurable by a Jira administrator because it does not require additional API calls. Any user can export this data into the selected Snowflake namespace.

Export Locations

This section allows an administrator to define Snowflake namespaces where users can store their exports. For each database in the list, check the checkbox for the schema(s) were you would like to allow users to create exports in that database.



After saving your Export Locations selections, users will see a Database/Schema item on the Export screen that, when clicked, will display a database selection drop down with the databases you specified.

If a user does not pick a database from this drop down when creating a new export, the export will be stored in the first available database.

Workflow Transition Post Function

Administrators may want to trigger export updates only when certain workflow transitions occur, instead of triggering updates every time an issue is created or edited. The add-on exposes a workflow transition post function to accomplish this goal. Since issue fields are typically edited during workflow transitions, we recommend you carefully consider your configuration of workflow transition post functions and how they may overlap with configured webhooks, since they present the possibility of firing multiple update events for a single change.

To configure a workflow transition that will call the post function, navigate to the workflow administration area by clicking on the Gear Icon in the top right, then selecting Issues and selecting Workflows on the left side.




Find the workflow you want to configure, and click the Edit item for that workflow.


In the workflow edit screen, find the transition you want to configure, and click the transition's name in the Transitions (id) column.


Click on the Post Functions tab for the transition, and then click Add post function.


Find the Snowflake Integration - Trigger Updates post function, and tick the radio button next to it, then click Add.



Click through the remaining screens as instructed. When you are finished making changes, click on the Publish Draft item at the top of the screen.


Complete the optional workflow backup steps and click Publish to finish your changes.