Limitations of Jira configurations

• Jira supports custom hierarchy levels. However, the Atlassian API does not allow to create issue types with hierarchy level other than 0, 1 and -1

• For issue types other with hierarchy level other than 0, 1 and -1 will be restored by Revyz with hierarchy level 0.

• Default issue type scheme cannot be updated. If an issue type is created, it is automatically added to the default issue type scheme.

• However, if extra issue types are present in the default issue type scheme, it will not be removed from the default issue type scheme.

Due to Jira API limitation, locked field can’t be updated or created.

Due to Jira API limitation, locked/system field can’t be updated or created.

• Atlassian doesn't provide the details of the context configuration for this type of field.

• Configuration refers to determining which schema to use and specifying which filters to apply when displaying results during object searches in the field.

If destination workflow is active, it is created with the suffix as an inactive workflow due to Atlassian Limitation.

1. If there are multiple global transitions(status with transition to itself) with same name, the workflow creation fails.

2. If directed transitions (transition from status-1 to status-2) and global transitions (transition from any status to itself) have same names.

3. If workflow name contains unnecessary white-spaces.

4. Plugins used in workflow should be present on both the site for the workflow creation to be successful.

During the workflow restoration using “Jira Configuration Clone” or “Project Clone” features, the "Compare Number Custom Field Condition" was restored as a "Value Field Condition" due to limitations with the Atlassian API.

When restoring workflows using the "Jira Configuration Clone" or "Project Clone" features, the "UserPermissionValidator" will not be restored due to limitations with the Atlassian API

• When restoring workflows using the "Jira Configuration Clone" or "Project Clone" features, the following object dependencies used in workflow rules must be manually created & mapped on the destination site:

  • Custom fields

  • Project roles

  • Issue security schemes

  • Groups

  • Statuses

  • Resolutions

• However, all workflow rules (validators, conditions, and post functions) will be restored.

If destination workflow scheme is active, it is created with the suffix as an inactive workflow scheme due to Atlassian Limitation.

Group can not be created & updated using connect app credentials due to Atlassian API limitation.

• Role actors cannot be added directly to a Project due to API limitation.

• Groups / Users can't be created or updated due to API limitation. If user / group is present on destination site then it will attached to project role.

1. If Jira site has free plan then permission scheme can not be created.

2. We don't update Permission scheme as it may adversely affect other Project permissions. Especially in case of Cross-Site clone where the Projects connected to a updated permission scheme may vary, it can result in unwanted permission exposure.

3. Groups/users can't be created or updated due to API limitation.

   1. While creating a permission scheme, if user / group is present on destination site then it will be attached to permissions used in the permission scheme.

1. Groups/users can't be created or updated due to API limitation. If user / group is present on destination site then it will attached to notification scheme.

2. Notifications of type user custom field & group custom field can not be created due to Atlassian API limitation.

3. Group mapping with the notifications is not returned by atlassian at the time of backup hence we can not restore it & the group mapping is only returned for default notification scheme and not for rest of the notification schemes.

4. We don't update notification scheme as it may affect other notifications which are already set.

1. Groups/users can't be created or updated - API limitation. If user / group is present on destination site then it will attached to issue security scheme.

2. Issue security levels mapping with user custom field & group custom field, project role & project lead can not be created due to Atlassian API limitation.

1. Not able to backup all the settings related to boards.

2. Revyz is not capturing board permissions - We will support this in future.

1. If all the components are present in JQL then only the filter will get created successfully.

2. Project clone - At the time of restore, If project is present on destination then we update the JQL, else we restore the same JQL.

1. Atlassian doesn’t have API support for the following hence Revyz app cannot clone it:

   1. Create or Modify a JSM Portal Settings / Groups.

   2. Create or Modify Workflow statuses in case of customized status names

   3. Create or Modify Request type fields which are used in ‘Request Forms’.

      1. If a Form was used in ‘Request Forms’ page then it will be restored as a new Forms template

   4. Create or Modify Request type fields which are added explicitly on ‘Issue view’.

      1. If the fields are added from Screens then it will be clone as expected. It is recommended that you update fields on ‘Issue view’ from the screen rather than ‘Request Types’ page.

   5. Create or Modify JSM project features

      1. It has to be manually enabled and the request types are to be linked post clone

2. Project clone - If new project is created, A default request types gets created which may not be a part of source project's request types.

• Issue priorities fails, if color hexadecimal has 3 or 4 digits as it is Atlassian restriction.

• When restoring status through “Jira Configuration Clone” or “Project Clone” features, the Icon_URL will not be restored due to limitation with Atlassian API