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.

• Project role cannot be selected while trying to perform a clone and restore on Jira configuration clone due to security concerns.

• 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.

4. During the cloning process, the permission scheme automatically creates a Project Role: atlassian-addons-project-access by default.

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.

• 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

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.

This document outlines the policy and technical limitations regarding the restoration of Jira Misc Workflow Extensions (JMWE) rules. Please review this information carefully to understand what can and cannot be restored.

Rules restore process

• Our restoration process focuses on non-scripted JMWE rules.

• Non-Scripted Rules: Only non-scripted JMWE rules are eligible for restoration.

• Scripted Rules:

  • Scripted JMWE rules are not fully restored.

  • While the shell of these rules may be created, the specific configuration objects used within these scripted rules cannot be created and replaced or re-linked automatically during the restoration process.

  • Manual re-configuration of the script content will be required for these rules.
    

• Limitations for Non-Scripted Rules

  • Shared Actions (JMWE app):

    • Shared Action ID: The Shared Action ID will not be created on the destination site and therefore will not be mapped to the post function.

  • Rules (Conditions, Validators, Post-functions) with Statuses:

    • While the associated statuses are restored on destination, their automatic mapping to post functions cannot be guaranteed. They may or may not be automatically mapped to their respective post functions.

    • The user will need to manually map these statuses after the restoration process.

  • SendSlackMessageFunction:

    • The backup and restoration of this specific post function is not handled by Revyz.Hence restore of this post function is not possible.

    • Workflow containing this post function will be restored, but the Send Slack Message post function itself will be dropped from the workflow.

    • It will need to be manually re-added and configured after restoration.