Jira Release Notes – Fivetran Support Portal

July 2022link

Now you can connect to your Jira Cloud instance using an API token. Now you can connect to your Jira on-premise instance using an application link. Refer to our Jira Setup Guide for details.

June 2022link

Now we use webhooks to keep the sprints in the up-to-date state in the destination.

NOTE: To use webhooks, you must have the Jira Administrators global permission.

As an alternative, we have added the SPRINT table to the BOARD group of tables, and now we sync all sprints entirely for particular board once a day.

May 2022link

We now sync the Affected Services, Customer Request Type, and Approvals fields with a customer request from Jira Service Management (formerly Jira Service Desk). We sync the Affected Services, Customer Request Type, and Approvals fields into the following tables:

APPROVAL
APPROVER
REQUEST
REQUEST_TYPE
SERVICE

See the Jira ERD for more information.

We are gradually rolling out this feature to all existing connectors. When it’s available for your connector, you will see the APPROVAL, APPROVER, REQUEST, REQUEST_TYPE, and SERVICE tables on the Schema tab. To fetch data for all issues, re-sync your connector.

NOTE: Previously, we only synced the name subfield in the Customer Request Type field. We kept this logic for compatibility. See the January 2021 Release Notes for more information.

April 2022link

We now sync issue watchers to the ISSUE_WATCHER table. We are gradually rolling out this feature to all existing connectors. Once this feature is available, you will see the ISSUE_WATCHER table on the Schema tab. To fetch data for all issues, re-sync your connector.

NOTE: We apply this feature both to new issues and existing issues once they are changed. Fivetran does not consider assigning and unassigning issue watchers a change in an existing issue since there is no initial state in an existing issue for us to compare to.

March 2022link

We now sync the following ISSUE custom field types:

Rank syncs to your destination as a lexorank algorithm string.
Team syncs to your destination as an integer value. The integer acts a team identifier. We had also added a new table, TEAM, that contains additional team data.

To learn how we sync custom fields for Jira, see our June 2020 release note.

February 2022link

You can now select Projects in the setup form to sync only their associated issues.

select_projects

January 2022link

We now sync the goal field of the sprint to the SPRINT table.

November 2021link

Now, we store a separate cursor for each project and use it to track updates in project issues. We can now sync all issues regardless of when the connecting user in your Jira instance was granted permissions for the relevant projects. Previously, we had a single cursor for all issues. When the user was granted permissions for a project after the initial sync had completed, we were not able to capture the old issues created before the user was granted permissions.

We now fetch issues in parallel threads, one for each project, which improves the extract time of the connector. We are gradually migrating all existing connectors to this new mode.

October 2021link

You can now specify the Consumer Key in the connector 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 provided was used by another external application in your Jira installation.

September 2021link

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

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

August 2021link

Now, if your Jira installation returns an HTTP 500 Internal Server error during a sync, we only skip the relevant issue field records from the sync. Previously, the entire sync failed.

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 pre-built, dbt Core-compatible data models for Jira. Find the models in Fivetran’s dbt hub or data models documentation. Learn more about our dbt Core integration in our Transformations for dbt Core documentation*.

* dbt Core is a trademark of dbt Labs, Inc. All rights therein are reserved to dbt Labs, Inc. Fivetran Transformations is not a product or service of or endorsed by dbt Labs, Inc.

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 labeled “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