Issue Summary

Changing the Issue type in projects through automation does not change the underlying workflow in the Database.

A4J provides an option to create a rule to change the issue type for JSM projects. This works good when issue types have same workflow.

However, in JSM projects, issue types are generally associated with different workflows. In such cases, the rule does not change the underlying workflow associated with the changed issue type in the database. The "changed/new" issue type will still be referring to the old workflow. This causes data corruption in the database (jiraissue DB table).

In JSW projects, this issue occurs when issue types are associated with different workflows and we try to change such issue types.

In UI screen, when the agent/admin tries to transition the issue, they see “You don’t have permission to transition this issue” message. This occurs even after agent/admin has sufficient permissions.

This is reproducible on Data Center: Yes

Steps to Reproduce

1. Pick a JSM (or JSW) project that has issue types associated with different workflows.
   
2. Create a simple rule where the "Issue type" and its Request type are changed through "Edit Issue" action. Here the destination issue type is "Incident".
   
3. Create an issue with "Service Request" issue type (any issue type except "Incident"). Assign the issue to user. (I am doing this step to trigger the rule. You can have any other triggers).
4. We see the rule is "Success" in the Audit logs.
   
5. In Issue page screen, the "Issue type" is changed to "Incident" and "Request Type" is also changed as expected.
   
6. Try to change the workflow status. We see You don’t have permission to transition this issue message.
   
   This is same for Jira Admin and agents who have "transition issue" and other admin permissions.
7. When we click on "View Workflow" below the error message. We see workflow related to Incident (changed) issue type. Which is as expected.
   
   

Expected Results

Jira Admin or agent should be able to transition the issue to different workflow status as they have the necessary permissions.

Actual Results

• Try to change the workflow status. We see You don’t have permission to transition this issue message.
  
  This is same for Jira Admin and agents who have "transition issue" and other admin permissions.
• When we click on "View Workflow" below the error message. We see workflow related to Incident (changed) issue type. Which is as expected.
  
  
• After enabling "DEBUG" packages, we see "State of issue [JSM-19] has an action [id=921] which cannot be found in the workflow descriptor" error messages.
  • DEBUG packages

    com.codebarrel.jira.plugin.automation.event
    com.codebarrel.jira.plugin.automation.queue
    com.codebarrel.automation.api.service

  • Error

    2023-09-07 09:01:11,215+0000 http-nio-8080-exec-3 ERROR admin 541x312x1 by2z8 172.29.182.146,172.50.0.2 /rest/api/2/issue/10400/transitions [c.a.jira.workflow.IssueWorkflowManagerImpl] State of issue [JSM-19] has an action [id=921] which cannot be found in the workflow descriptor
    2023-09-07 09:01:11,215+0000 http-nio-8080-exec-3 ERROR admin 541x312x1 by2z8 172.29.182.146,172.50.0.2 /rest/api/2/issue/10400/transitions [c.a.jira.workflow.IssueWorkflowManagerImpl] State of issue [JSM-19] has an action [id=851] which cannot be found in the workflow descriptor

• Even though ‘Automation for Jira’ is changing the issue type and workflow displayed at UI (view issue) screen, it is not changing the underlying workflow associated with the issue. Certain changes are done at the backend, but not completely.
• The error messages are telling that Issue (JSM-19) is trying to do transitions/actions that are not associated with its workflow. For some steps, workflow related to ‘Incident’ (JSM: Incident Management workflow for Jira Service Management) is referred, for others workflow related to ‘Service Request’ issue type (JSM: Service Request Fulfilment workflow for Jira Service Management) is referred.
• As per the above logs, action [id=921], [id=851] etc are action IDs of workflow belonging to issue type Service Request. However, Jira is validating their actions with workflow belonging to issue type Incident causing this error.
• In the DB, the issue JSM-19 is still referring to Workflow ID of JSM: Service Request Fulfilment workflow for Jira Service Management workflow which is linked with “Service Request” issue type.

  jira=# select issuenum, workflow_id from jiraissue
  jira-# where project in (select id from project where pkey = 'JSM')
  jira-# and issuenum in (19);
   issuenum | workflow_id 
  ----------+-------------
         19 |       10400

  JSM-19 is still referring to “10400” workflow ID which belongs to “JSM: Service Request Fulfilment workflow for Jira Service Management”.

• Even though A4J changes the workflow in UI, in DB the changes are not updated. The issue will still be referring to the old workflow (JSM: Incident Management workflow for Jira Service Management).

  jira=# select * from os_wfentry where id = 10400;
    id   |                                 name                                 | initialized | state 
  -------+----------------------------------------------------------------------+-------------+-------
   10400 | JSM: Service Request Fulfilment workflow for Jira Service Management |             |     1
  (1 row)

Workaround

• Don't use "Edit Issue" action to change the "Issue type" when their underlying workflows are different.
• We can "manually" use the "Move Issue" option to change the "issue type" when their underlying workflows are different.

Note

We have a Feature Request - Ability of editing Issue Types that use different workflows to implement ability to change issue types with different workflows. Currently "Edit Issue" displays a warning against data corruption.

Raising this as a Bug because the A4J rule updates the issue type without showing any error in the audit logs, while it actually causes some inconsistency in the DB.

Ideally, the A4J rule should somehow detect that the new issue type belongs to a new workflow, and instead of updating the issue type, maybe it should just stop, and throw some error in the audit logs. This way, no damage to the data consistency is made.