In most cases, you can safely skip reading this section. If the import stops because drafts cannot be automatically published, this means that the new configuration has a big impact on issues of existing projects (to the point of requiring changes to the status in some of the issues). On a reasonably planned and executed operation, this should be quite rare.
When applying the project configuration, changes to active workflows or workflow schemes will not be applied directly to those workflows or schemes, but to a draft workflow or draft scheme (see this page for further details). The plugin will try to automatically publish these drafts before going on with the import of issue data and attachments. Most often this will succeed, but there are a few times when user intervention will be required, usually for mapping existing issues to the new statuses implied by the new schemes.
In this cases, the import will stop after importing the configuration and will show a screen like this:
It contains a message that asks you to publish standing drafts before proceeding with data import.
For greater convenience, there are detail messages about each draft scheme that has to be published under "Import warnings", including a link to the page where the user can choose the status mapping for existing issues. No equivalent link is provided for workflow drafts. Please see below for a discussion of the situation when a workflow draft cannot be published automatically.
Once all drafts have been published, click on "Next" to continue with data import.
A workflow draft cannot be published when it does not contain all the set of statuses of the original workflow or they are not mapped to the same workflow step IDs. If you encounter such a draft in this stage,
- It means the workflow existing in the target instance, and the existing issues using that workflow, have an incompatible set of statuses with the new version of that workflow coming from the source instance.
- It is very difficult in practice to fix that incompatibility, as the new set of statuses and mapped workflow step IDs will be used by issues coming from the source instance. So the fixing would require the draft to be compatible at the same time with both the existing statuses and mapped setp IDs of the source and target instance. This will likely be quite difficult to achieve and sometimes simply impossible.
- The logical and simplest solution to this problem is to avoid the coincidence of workflow names between both instances. For example, go back to the source instance, rename that workflow to a name that is not used by any workflow in the target instance, repeat the export and retry the import with the new file.
How to rename a workflow
- Create a copy of the workflow with the desired new name.
- For every workflow scheme that uses that workflow,
- Change it, replacing the original workflow with the new copy
- Publish the changes to the workflow scheme
- Now the original workflow should be inactive, as it is not used in any workflow scheme. You can delete it, if it is no longer necessary.