Jira Release Notes – Fivetran Support Portal

October 2021link

You can now specify the Consumer key in the Setup Form while creating an application link between Fivetran and your Jira installation. Previously, it was impossible to create an application link if the Consumer key we were providing was used by another external application in your Jira installation.

September 2021link

Now we capture deleted projects using webhooks. We’re gradually rolling out to all existing connectors.

NOTE: We can’t capture project deleted before your Jira connector registered the webhook in your Jira installation.

August 2021link

Now we just skip any relevant issue field record during the sync if your Jira installation returns the HTTP 500 Internal Server error. Previously, the entire sync would fail in that case.

June 2021link

We now sync system Jira fields, such as project andpriority, even if there are custom fields with the same names. Previously, we skipped all fields that had the same names. This feature applies to connectors set up before September 10, 2020. Connectors created after this date sync all fields regardless of the names.

We have added a new field, is_active, to the ISSUE_FIELD_HISTORY and ISSUE_MULTISELECT_HISTORY tables. The field allows you to assemble the complete current state of an issue without a full table scan. It is true for the current issue records and false for historical issue records. To get values in the is_active field for all issues, re-sync your connector. We are gradually rolling out this feature to connectors set up after September 10, 2020.

May 2021link

We have added a new column, author_id, to the ISSUE_FIELD_HISTORY and ISSUE_MULTISELECT_HISTORY tables.

This column stores the identifiers of the users who made changes to a given Jira issue. This feature applies to all connectors set up after September 10, 2020. Re-sync your existing connector to sync this data for all historical changes.

April 2021link

Now you can sync the following table groups by checking the relevant group checkbox on the Schema tab of the connector details page:

BOARD, ISSUE_BOARD, PROJECT_BOARD
PERMISSION_SCHEME, PERMISSION, PERMISSION_HOLDER
SECURITY_SCHEME, SECURITY_LEVEL, SECURITY_SCHEME_LEVEL.

NOTE: When sync is enabled for any of these groups, all tables within the selected groups are re-synced once a day.

Now we sync the historical changes of the key field.

March 2021link

We now sync entries related to Jira permissions. We are gradually rolling out this feature to all existing customers. Once this feature is available for your connector, you will see the following items in your destination:

The PERMISSION, PERMISSION_SCHEME, PERMISSION_HOLDER, PROJECT_ROLE tables
The permission_scheme_id column in the PROJECT table See Jira Schema Information section for details.

We have added a new column, _fivetran_deleted, to the FIELD table. Now we capture custom fields deleted from source.

We now sync the Security Level field.

We now sync Issue Security Schemes. We are gradually rolling out this feature to all existing customers. Once this feature is available for your connector, you will see the SECURITY_SCHEME, SECURITY_LEVEL, and SECURITY_SCHEME_LEVEL tables in your destination.

February 2021link

We now support the Satisfaction and Satisfaction date fields of Jira Service Management (formerly Jira Service Desk).

January 2021link

We now use the X-Force-Accept-Language header to get responses in English. This applies to all Jira connectors created after February 1, 2021.

We now support the name subfield in the Customer Request Type field of Jira Service Management (formerly Jira Service Desk).

December 2020link

We now automatically capture deletes for Jira connectors. We have removed the “Capture deletes” toggle from the connector setup form. To be able to capture deletes, you must have the Jira Administrators global permission. We cannot capture deleted issues that were deleted before sync deletes was enabled. To get all deleted issues, re-sync your connector.

We have released a pre-built dbt package for Jira. Find the package in Fivetran’s dbt hub. Learn more about our dbt integration in our dbt Transformations documentation.

We have fixed capturing of array fields such as components and fixVersions in the ISSUE_MULTISELECT_HISTORY table. Now we write null instead of "0" for empty values. The value and _fivetran_id column values for the relevant records will be updated during the next sync.

November 2020link

We now fully support the cascading select fields in Jira issues. We’ve added a new parent_id column, which refers to the parent value, to the FIELD_OPTION table. To sync fields of this type for all issues, re-sync your connector.

October 2020link

We have improved how we sync historical changes for the standard issue array fields components, fixVersions, and versions. We now write the actual values for each historical change, making the table much easier to use. The Jira API delivers empty values if part of the value is removed, and previously we just wrote that empty value.

We now support the Jira Service Management (formerly Jira Service Desk) Organization fields in Jira issues. To sync fields of this type for all issues, re-sync your connector.

September 2020link

We enable the improved schema by default for connectors set up after September 10, 2020. See our June 2020 release note for details about the improvements, which were previously opt-in, but are now default.

August 2020link

We have added a new column, is_public, to the COMMENT table.

We have improved the mechanism that detects similar fields that might cause data integrity issues. When we detect that similar field names would become duplicate names after normalization, we do not sync them to your destination. Instead, we show a warning on your dashboard and ask you to rename the fields. This prevents duplicates in the destination and avoids writing the values of the different fields into the same history table.

To prevent data integrity issues, we will sync some standard fields in the following way:

Σ Original Estimate field to the ISSUE_AGGREGATE_ORIGINAL_ESTIMATE_HISTORY table
Σ Time Spent field to the ISSUE_AGGREGATE_TIME_SPENT_HISTORY table
Σ Remaining Estimate field to the ISSUE_AGGREGATE_REMAINING_ESTIMATE_HISTORY table
Σ Progress field to the ISSUE_AGGREGATE_PROGRESS_HISTORY table.

We have also improved the mechanism that detects the Jira changelog to avoid syncing values from one field into multiple history tables.

July 2020link

We have changed the styling of the connector name from “JIRA” to “Jira” in the Fivetran dashboard to match Atlassian’s official styling.

June 2020link

We have added a new way to sync issue field values and their historical changes. Previously, customers whose ISSUE table had a large number of fields found that it was generating an overwhelming amount of ISSUE_[FIELD_NAME]_HISTORY tables.

Now, the ISSUE table contains only columns for the Jira standard fields.

We added a FIELD table that contains information about all fields. We sync all values from the custom non-array fields and their history items to a single ISSUE_FIELD_HISTORY table. We sync all values from the array fields and their history items to a single ISSUE_MULTISELECT_HISTORY table. We sync initial null values from history items to the history tables to provide a better historical analysis.

If you would like to use this new method, contact our support team to enable it. Then, create a new connector or re-sync the existing one.

We have improved the mechanism that detects the changelog. Now, if a fieldId is not present in the Jira response, we will find the changelog entries using a fieldname. This improvement prevents data integrity issues when the current field value is written into the history table as initial.

May 2020link

You can now configure your Jira connector using the Fivetran REST API. This feature is in BETA and available only for Standard and Enterprise accounts.

March 2020link

Previously, when there were multiple changes in the source during the sync, our connector sometimes missed some data. We have fixed this problem by changing our pagination strategy. To ensure that all your data is synced, re-sync your connector.

January 2020link

When the value of a field was null, our Jira connector didn’t always update array values. That meant that, for example, if the value was removed from a field in the source, sometimes the destination still showed the previous value. Now when a field value is null, our Jira connector will write a default empty value according to the type of the field.

Our Jira connector can now sync issues from January 1, 1970 forward. Previously, our connector only synced issues from January 1, 2002 forward. If you have issues from 1970-2002, perform a re-sync to ensure that we capture all issues.

September 2019link

We can now sync empty array type fields, such as labels. This means that any removed values will be accurately reflected in the destination. Previously, we could not sync array fields with null values, which meant that some values deleted in the source were not deleted in the destination.

We now track deletes in the WORKLOG table. This means that any deleted work logs will be accurately reflected in the destination.

August 2019link

We now support SLA fields in Jira issues. We are gradually rolling out this feature to all our customers. When it’s available for your connector, you will see an additional sla table in your destination. You can see the SLA table on our Jira ERD. To sync all SLA fields, resync your connector.

July 2019link

We now support capturing deleted issues by using webhooks. We are gradually rolling out this feature to all our customers. When it’s available for your account, you will see a switch on the Jira connector setup form labelled “Capture deletes”. To enable capturing deletes, toggle the switch.

May 2019link

We have added the WORKLOG table. To sync the WORKLOG table, create a new connector or re-sync the existing one.

May 2018link

We have dropped the primary key constraint from the value field in the ISSUE_[FIELD]_HISTORY and ISSUE_[FIELD] tables.

April 2018link

We now remove the relationship between an issue and an issue label if the issue is removed in Jira.

If you deploy your Jira to a custom root path, you can now specify that path in our setup form:

JIRA setup form