Details
-
Bug
-
Resolution: Won't Fix
-
Medium
-
1
-
Severity 1 - Critical
-
Description
Summary
When using a CSV import to update a moved issue, it incorrectly moves the issue back to the previous project and viewing the issue is no longer possible.
Steps to Reproduce
- Import or create an issue, for example MWK-1.
- Move issue to another project, in this example it becomes TECH-2. This can also involve changing things such as version and component, which are project-specific.
- CSV import the issue using the old key MWK-1.
Expected Results
The TECH-2 issue is updated, using the data from MWK-1 (it will correctly find the issue using the moved_issue_key table).
Actual Results
The issue key is moved back to the old project - for example TECH-2 is moved into the MWK project, and keeps the correct issuenum (3). Additionally, the below exception is thrown when attempting to view MWK-1, and TECH-2 will 404.
java.lang.IllegalArgumentException: Passed List had more than one value. at org.ofbiz.core.entity.EntityUtil.getOnly(EntityUtil.java:62) [entityengine-1.2.3.jar:?] at com.atlassian.jira.issue.managers.DefaultIssueManager$IssueFinder.getIssueFromIssueEntityByProjectAndNumber(DefaultIssueManager.java:986) [DefaultIssueManager$IssueFinder.class:?] at com.atlassian.jira.issue.managers.DefaultIssueManager$IssueFinder.getIssueFromIssueEntity(DefaultIssueManager.java:982) [DefaultIssueManager$IssueFinder.class:?] at com.atlassian.jira.issue.managers.DefaultIssueManager$IssueFinder.getIssue(DefaultIssueManager.java:959) [DefaultIssueManager$IssueFinder.class:?] at com.atlassian.jira.issue.managers.DefaultIssueManager.getIssue(DefaultIssueManager.java:140) [DefaultIssueManager.class:?] at com.atlassian.jira.issue.managers.DefaultIssueManager.getIssueObject(DefaultIssueManager.java:340) [DefaultIssueManager.class:?] at com.atlassian.jira.bc.issue.DefaultIssueService.getIssue(DefaultIssueService.java:170) [DefaultIssueService.class:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [?:1.8.0_20] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [?:1.8.0_20] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [?:1.8.0_20] at java.lang.reflect.Method.invoke(Method.java:483) [?:1.8.0_20]
See [^full_stack_trace] for more info.
Notes
Looking into the database we can see the problem is the project key is changed back to what it was. Prior to the import:
select * from jiraissue; id | pkey | issuenum | project | reporter | assignee | creator | issuetype | summary | description | environment | priority | resolution -------+------+----------+---------+----------+----------+---------+-----------+---------+-------------+-------------+----------+------------ 10000 | | 1 | 10001 | admin | | admin | 10005 | 1 | | | 3 | 10002 | | 2 | 10000 | admin | | admin | 10001 | 2 | | | 3 | 10003 | | 3 | 10000 | admin | | admin | 10001 | 3 | | | 3 | 10001 | | 2 | 10001 | admin | | admin | 10005 | 1 | | | 3 | (4 rows)
And after:
select * from jiraissue; id | pkey | issuenum | project | reporter | assignee | creator | issuetype | summary | description | environment | priority | resolution -------+------+----------+---------+----------+----------+---------+-----------+---------+-------------+-------------+----------+------------ 10000 | | 1 | 10001 | admin | | admin | 10005 | 1 | | | 3 | 10002 | | 2 | 10000 | admin | | admin | 10001 | 2 | | | 3 | 10003 | | 3 | 10000 | admin | | admin | 10001 | 3 | | | 3 | 10001 | | 2 | 10000 | admin | | admin | 10001 | test | | | 3 | (4 rows)
The moved_issue_key table is not updated:
select * from moved_issue_key ; id | old_issue_key | issue_id -------+---------------+---------- 10000 | MWK-1 | 10001 (1 row)
Workaround
The issue cannot be accessed to be moved, unless through bulk edit. Then when moving the issue back to TECH, it will create a new issue key (such as TECH-3). MWK-1 will then not redirect to TECH-3 and anything linked to TECH-2 will break. As such a SQL update is needed. For example:
- Stop JIRA.
- Identify the appropriate project:
select id from project where pkey = 'TECH'; id ------- 10001 (1 row)
- Update the issue to have the correct project:
update jiraissue set project = 10001 where id = 10001; UPDATE 1
- Start JIRA and reindex.
This will allow updating with CSV, however any affected issue keys will need to be restored after the import. The alternative is to not map the issue key field however then new issues will be created instead of updating old ones.
Original Description
I saw this in the online version
Steps to reproduce
- Import an issue
(ABC-154)- Move issue to another project (changing version and component)
(XYZ-232)- Import issue comments using old key.
- Comments import successfully
Problems:
- Moves issue back to old project (but retains new issue number).
(ABC-232)- Second key does not redirect
(XYZ-232 is not found)
First key does still re-direct- The project specific field values are not changed (component and version refer to wrong project).
Workaround: Move the project back to the new project (XYZ-457)
This was very confusing and I'm not sure what problems it would have caused (mostly regarding the mismatched fields) if I had not found it when doing verification. It seems like a bad state for the issue to be in.
