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 snapshot, users will only be exported if they are referenced by the exported configuration objects or issue data.

• When the user is created on deployment of the configuration snapshot, the system will generate a new password for the created user. This password cannot be accessed or viewed and can only be reset by the user through the Can’t access your account? button on the target Jira instance.

• If a user must be added when deploying a configuration snapshot, the user will be added to the default directory (i.e., the first directory with Create user permissions). Note that a warning is also logged in the Audit Log. During a snapshot deployment, if the "Project Roles" option is unchecked, CMJ will skip adding any users used in a project configuration or mentioned in the project’s issues. In this case, the Project lead will still be added.

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 the exported 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 deployment, any associated issue will lose its relation to that component. By default, the deletion of components 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 that 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, the 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 a configuration that 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 that 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:

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

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

  • the 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 an issues snapshot, there are custom field values for this custom field.

Custom Field Contexts

The behavior 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

Filters

• Snapshots can include selected filters. For project snapshots, filters may refer to multiple configuration objects that 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 that 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 that 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.