Possible loss of data integrity when assigning a workflow scheme to an existing project

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:
    1. Run a first import skipping "Project (changes)"
    2. 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.
    3. 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:

  • The issues keep following the old workflow
  • The buttons for the transitions are not shown in the issue page
  • When viewing the issue the JIRA log shows a message like this:

    [atlassian.jira.workflow.IssueWorkflowManagerImpl] State of issue [XXXX-2] has an action [id=21] which cannot be found in the workflow descriptor
  • When viewing the issue, the link "View workflow" does not work.
  • The integrity checker reports an error like this:

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:

  1. 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").
  2. 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.
  3. (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).