Limitations of Jira Issues

About this Page

This page details the specific limitations and behaviors of the Revyz app when backing up, restoring, or cloning Jira Issues.

It covers known constraints and exceptional cases, such as how issue security levels can prevent backups, why a restored issue's status might differ due to workflow restrictions, and how the assignee field is handled if the user doesn't exist on the destination.

Jira Issues

If issue is locked using issue security level and Revyz app doesn’t have access using the same issue security level then:
- The same Issue can’t be backed up.
- Also if this issue is linked to any other issue / asset objects then we can’t store that link ( we don’t receive the link from Jira) .

Project types to clone Jira Issues

Currently Revyz supports issue restore for
- Company managed to Company managed projects
- Team managed to Team managed projects

Why is the status of the restored issue different from the status of the source issue?

When using the "Create New Copy" option to restore an issue, please note that the status of the new issue may differ from the source issue due to workflow restrictions in the destination project.
In such cases, Revyz provides the status code R_01005 in the job details CSV file and logs.
Post-Action
- To address this issue, It is recommended to review and update the workflow configuration of the destination project to allow the required status transition.
- Alternatively, manually adjust the status of the restored issue after restoration.

Does Revyz restore the comment in an issue?

Revyz effectively restores comments, including details such as the name of the comment creator and the timestamp of the comment.
Additionally, internal comments from the service desk project can be restored as customer comments.

Does Revyz restores the assignee field in the issue?

Yes Revyz restores assignee field in the issue.

Exceptional cases:

If the user assigned in the Assignee field is not available on the destination

The Assignee is set to the Default Assignee (Project Lead) or Unassigned, depending on the configuration of the destination project.

If assignee user is not available on the destination and default assignee (project lead) does not have assignable user permission

The issue will be set to unassigned.

If the assignee is not available in the destination and the default assignee is set to unassigned, but the "Allow unassigned issues" option is turned off (configurable in general settings),

Issue creation fails.

If the assignee is not available in the destination, the default assignee (project lead) lacks assignable user permissions, and "Allow unassigned issues" is turned off (configurable in general settings).

Issue creation will fail.