Mobile app allows users to edit Issue Type without verifying workflow differences

Just as the CSV import process has no verifications for certain Issue Update operations (i.e. updating issue types), the Jira mobile app allows users to update Issue types even when the destination type uses different workflows, screens, fields.

This cause some inconsistencies in the database, as the workflow association is not updated accordingly for an example.

Steps to reproduce:

1. First, it is required that a project uses different workflows for different issue types, like in the example below:
   
2. Then, in a mobile app, edit an issue's issue type to another that uses a different workflow (i.e. From Bug to Build and Unit Test)

Expected result:

• Issue types that use different workflows should not be available in the picklist

Actual result:

• All issue types related to the project are displayed, allowing you to move to an issue type that uses a different workflow

Identifying the problem:

• In order to identify whether an issue is impacted by this, check the database to verify that it is still associated with the original workflow, instead of the expected one:

  select ( p.pkey || '-' || i.issuenum) as issue_key, wse.workflow, wfe.name from jiraissue i join project p on i.project = p.id join nodeassociation na on (na.source_node_id = p.id and source_node_entity = 'Project' and na.sink_node_entity = 'WorkflowScheme') join workflowscheme ws on ws.id = na.sink_node_id join workflowschemeentity wse on wse.scheme = ws.id and wse.issuetype = i.issuetype join os_wfentry wfe on wfe.id = i.workflow_id where wse.workflow != wfe.name union
  select ( p.pkey || '-' || i.issuenum) as issue_key, wse2.workflow, wfe.name from jiraissue i join project p on i.project = p.id join nodeassociation na on (na.source_node_id = p.id and source_node_entity = 'Project' and na.sink_node_entity = 'WorkflowScheme') join workflowscheme ws on ws.id = na.sink_node_id left join workflowschemeentity wse1 on wse1.scheme = ws.id and wse1.issuetype = i.issuetype join workflowschemeentity wse2 on wse2.scheme = ws.id and wse2.issuetype = '0' join os_wfentry wfe on wfe.id = i.workflow_id where wse2.workflow != wfe.name and wse1.issuetype is null
  

• The results below describe the fact that the issue type was expected to be associated with the BP: Process Management Workflow, but it's still associated to it's original one, Software Simplified Workflow for Project CEA

  issue_key,workflow,name
  CEA-52,BP: Process Management Workflow,Software Simplified Workflow for Project CEA
  

Symptoms:

• This not only causes inconsistencies in the database but also in the UI. In the example above, the issue is displayed as if it was in the original workflow's status, which doesn't necessarily exist in the workflow actually associated with that issue type