API Limitations
The backup & restore application is built using the API’s provided by Atlassian (https://developer.atlassian.com/cloud/jira/platform/rest/v3/intro/ ). The API’s provided are not specifically designed to address the backup & restore use case, because of which there are limitations on how these API’s can be used for backup & restore of your Jira Software cloud site.
The Atlassian team is working on newer API’s specifically to address the backup & restore use case(s). More information can be found on the status of those API’s here (https://community.atlassian.com/t5/Backup-Restore/gh-p/backupandrestore ).
Note - to access this Atlassian community site you would need have login into the Atlassian community site and be a member of the Backup & Restore group.
As and when newer and more targeted API’s become available Revyz will update accordingly.
Known limitations - This is not a comprehensive list of all known limitations, we will keep adding as and when we learn.
Restoration of deleted Jira ticket KEY
Once an issue is deleted, the key associated with the deleted issue cannot be reused.
Example: Issue with key KEY-101 is deleted
In the backup (assuming a backup was taken prior to the deletion of KEY-101) you will find the issue KEY-101, and when it is restored back using Revyz, it will get a new key ID which corresponds to next highest key available in that project.
KEY-101 → KEY-578 (Restored Key ID)
Some use cases are very much dependent on key ID’s as these key ID’s are are referenced by other third-party applications and thus key ID’s are important.
Workaround:
Update the new key in other dependent applications manually
Reference to the old key and complete issue data is attached to the ticket in csv & json formats
Restoration of all fields in an issue
The Issue creation API’s available are designed to work very well with Jira UI. They also follow the same steps as one would follow on the UI to create an issue followed by updating an issue:
Creating an Issue - POST /rest/api/3/issue - Only the fields visible during the Issue creation operation can be restored back in using this API call
Updating an Issue - PUT /rest/api/3/issue/{issueIdOrKey} - Only the fields visible during the Issue update operation can be restored back in using this API call. This gets more complicated if the screens have fields which are based on the status of the Issue
The net result is in some cases all fields are not restorable.
Timestamp of issue creation and update times are lost
Workaround:
Reference to the complete original issue data is attached to the ticket in csv & json formats and all fields and corresponding data can be retrieved
Issue status
In restoring an issue as a new issue, we go through the process of:
Creating a new issue
Updating the newly created issue to restore as many fields of data possible
In some scenarios the Issue status cannot be updated to what it originally was unless the previous status was per the transition rules for that issue type. The net result is that the restored issue may not have the same status as it was when it was backed-up.
Workaround:
Update the status of the issue manually
Reference the original complete issue data attached to the ticket for the original status
Not all Jira objects are restorable
Some of the Jira objects do not have a POST API, because of which while we may backup that object, it will not be restorable.
As an example, object Resolution does not have a POST API
Over the course of time the Revyz app will be backing up all Jira objects that are restorable. Reference the Jira Backup page to get a complete list of all the objects that are supported by the Revyz app that are backed-up and are restorable .