Special Cases

 

On this page:

 

This page contains information specific to some configuration object types.

Users

  • Users are never deleted or changed if they exist, and user passwords are not exported in a configuration snapshot. 

  • When creating a configuration snapshot, users will only be exported if they are referenced by other configuration objects.

  • When the user is created on deploy of the configuration snapshot, the system will generate a new password for the created user.

  • If a user must be added when deploying a configuration snapshot, the user will be added in the default directory (i.e. the first directory with Create user permissions). Note a warning is also logged in the Audit Log. If the option "Do not merge changes to Project Roles" is selected and the user is referred only by a project role then the user addition will be skipped during the deployment.

Groups

  • Groups are never deleted or changed if they exist.

  • When creating a configuration snapshot, groups will only be exported if they are referenced by other configuration objects. Note the exported group will be empty.

  • If a group must be added when deploying a configuration snapshot, the group will be added as an empty group - it is up to the user to configure the group. Note a warning is also logged in the Audit Log.

Projects

Components

  • If a project component is deleted during the deploy, any associated issue will lose its relation to that component. By default, deletion of component used in issues will stop the deployment.

Versions

  • If a version is deleted during the deployment, any associated issue will lose its relation to that version. By default, deletion of the version used in issues will stop the deployment.

Custom Fields

  • All custom fields which come by default with Jira are supported, including single/multi-select lists, radio buttons, checkboxes and cascading select.

  • Third-party custom fields are also supported. However, their custom options may not be exported in some cases. This means that some third party custom fields will be exported when doing a configuration snapshot without their options and these options will not be part of the diff for the source and target configurations and will not be changed.

  • When creating a project configuration snapshot, project picker custom field default values for only the given project will be exported. This means if you have a project picker custom field with configuration which uses another project (i.e. not the exported one) for a default value, the default value will not be exported. This is done to prevent referencing non-existent projects when deploying.

  • When importing changed options in custom fields (multi-select, select list, cascading select, etc.) the changed options will not be deleted from the configuration. Instead, the changed options will be disabled in the target Jira. This feature is intended to minimize problems with issues which may use that option in a field value. When this happens during deployment a warning is logged in the Audit Log.

  • In project snapshots custom fields are exported if:

    • field is referenced by workflow, assigned to the project;

    • field is referenced by scheme, assigned to the project;

    • field is referenced by at least one screen, assigned to the project;

    • If the Include custom fields with value in at least one issue option is set and the above conditions are not met, it will be checked if there are any issues in the project for which the custom field has a non-empty value and if any it will be included

    • In a project with issues snapshot, there are custom field values for this custom field.

Custom Field Contexts

The behaviour described below applies only when creating/deploying project configuration snapshots.

  • Only contexts of the projects selected for the snapshot are exported for each custom field - these are either a global context or the contexts for the projects for which the snapshot is created. Contexts in the project snapshot do not contain references to other projects (that are not part of the selected for the snapshot), even if such were present on the source system.

  • If a context needs to be deleted from the target and it references multiple projects, only the reference to the projects for which the snapshots are created is removed from the context.

  • The global context is never deleted from the target as this may affect many projects.

  • Prior to CMJ version, 6.5.0 Custom field contexts are matched by the following strategies in order:

    • If the context has options it is matched based on the options, default value, issue types and name;

    • If no match was found and the context has options it is matched based on the options, default value and issue types (without the name);

    • If no match was found the context is matched based on the scope - global or projects, i.e. two contexts with the same set of projects for their scope will be matched.

  • After CMJ version 6.5.0 support for editing custom field contexts is added and contexts are matched based on the scope - global or projects, i.e. two contexts with the same set of projects for their scope will be matched

Field Configuration Schemes

  • The default scheme "System Default Field Configuration" is not exported when creating snapshots, because it cannot be modified.

Workflow Schemes

  • The default scheme "Default Workflow Scheme" is not exported when creating snapshots, because it cannot be modified.

Workflows

  • The default workflow is not exported when creating snapshots, because it cannot be modified.

Conditions, Validators and Post-functions

There is support for conditions, validators and post-functions defined in a standard Jira, plus the one specified in the Supported Apps. Workflow extensions defined in other plugins may not load correctly.

If you need support for workflow extensions defined by an app, please raise an issue.

Filters

  • Snapshots can include selected filters. For project snapshots, filters may refer to multiple configuration objects which may not be referenced by the projects' configuration. In this case, you will be presented with a warning when creating the snapshot. The filters can still be deployed but in order to work properly, the missing objects must be present on the target system.

Agile Boards

  • Snapshots can include selected agile boards. For project snapshots, agile boards may refer to multiple configuration objects which may not be referenced by the projects' configuration. In this case, you will be presented with a warning when creating the snapshot. The boards may or may not be deployed depending on the criticality of the missing objects. In any case, an appropriate message will be shown and in order for the boards to work properly, the missing objects must be present on the target system.

Dashboards

  • Snapshots can include selected dashboards. For project snapshots, dashboards and their gadgets may refer to multiple configuration objects which may not be referenced by the projects' configuration. In this case, you will be presented with a warning when creating the snapshot. The dashboards may or may not be deployed depending on the criticality of the missing objects. In any case, an appropriate message will be shown and in order for the dashboards to work properly the missing objects must be present on the target system.