In some cases, when a configuration is imported some issue data related to workflows may become inconsistent. This problem affects Project Configurator versions until 1.12.1-JX. If you are running one of these versions, please upgrade as soon as possible to a newer one (scheduled for May 4th 2016). Keep reading the rest of this article for further details.
When does it happen
This problem will occur when all these conditions are true:
- A configuration is imported for a project that already exists in the target instance and has some issues.
- During the import that project is assigned a new workflow scheme.
- As a result of the import some of the issue types in the project must change to a different workflow and some of the previously existing issues in the project have these issue types.
If all these conditions hold, the configuration import does not update correctly the existing issues to the new workflows.
How to avoid it
The easiest and most immediate way is using a version of Project Configurator where this issue has been fixed. If this is not possible, follow this advice:
- Run always a simulated import before the real one.
- Check if the import would assign a new workflow scheme to an existing project. Search the simulated import trace for lines like this, where XXXX would be the key of the project:
INFO 13:12:27,140 [Project XXXX] Associating to workflow scheme: YYYY YYYYYY
- If project XXXX already exists in the target instance and it has some issues, and if the new workflow scheme will change the workflow mapped to those issues, then run the real import in these three steps:
- Run a first import skipping "Project (changes)"
- Assign manually the new workflow scheme (if it did not exist, it will have been created by the first import in step a) to project XXXX.
- Run a second import without skipping "Project (changes)"
The visible effects vary depending on the exact difference between the new and the old workflows assigned to the issues. They may include some of these:
How to detect it
Run this query on the JIRA database, where 'XXX', 'YYY' are the keys of the projects you want to check:
select distinct project.pname, issuetype.pname, os_wfentry.name from project, issuetype, jiraissue, os_wfentry where jiraissue.project = project.id and jiraissue.issuetype = issuetype.id and jiraissue.workflow_id = os_wfentry.id and project.pkey in ('XXX', 'YYY') order by project.pname, issuetype.pname
This query will return all existing combinations for any issue of:
- The name of the project it belongs to
- The name of its issue type
- The name of the workflow it is using
"Simple issue tracking XXX","New Feature","XXX: Simple Issue Tracking Workflow"
"Simple issue tracking XXX","Task","XXX: Simple Issue Tracking Workflow"
Compare, for each project, this resut with its current workflow scheme (see below image). If the associations reported by the query differ from the mappings defined in the workflow scheme, then your instance is affected by this problem.
How to fix it
This problem can be fixed quite easily. For each affected project, repeat these steps:
- Go to "Administration" → "Issues" → "Workflow schemes". Create a copy of the workflow scheme assigned to the project (let us suppose the assigned scheme is named "WS" and the copy is cretaed with the name "Copy of WS").
- Go to the project administration page, and to the "Workflows" section. Click there "Switch Scheme" and select the copy scheme just created "Copy of WS". Follow the steps indicated by JIRA to complete this change.
- (Optional) If the old workflow scheme "WS" is not used by any other project, you can remove it and rename "Copy of WS" to "WS" (to keep the same names as at the beginning of the fixing process)
If several projects have to be fixed, and some of them share the same workflow scheme, it has to be copied only once (step 1 above).