java.lang.IllegalArgumentException: Passed List had more than one value.

Atlassian JIRA | Jesika DiGregorio | 2 years ago
  1. 0

    h3. 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. h3. 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. h3. 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). h3. 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. {noformat} 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] {noformat} See [^full_stack_trace] for more info. h3. 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: {noformat} 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) {noformat} And after: {noformat} 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) {noformat} The {{moved_issue_key}} table is not updated: {noformat} select * from moved_issue_key ; id | old_issue_key | issue_id -------+---------------+---------- 10000 | MWK-1 | 10001 (1 row) {noformat} h3. 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: {noformat} select id from project where pkey = 'TECH'; id ------- 10001 (1 row) {noformat} # Update the issue to have the correct project: {noformat} update jiraissue set project = 10001 where id = 10001; UPDATE 1 {noformat} # 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.

    Atlassian JIRA | 9 months ago | Ismael Jimoh [Atlassian]
    java.lang.IllegalArgumentException: Passed List had more than one value.
  2. 0

    h3. 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. h3. 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. h3. 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). h3. 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. {noformat} 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] {noformat} See [^full_stack_trace] for more info. h3. 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: {noformat} 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) {noformat} And after: {noformat} 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) {noformat} The {{moved_issue_key}} table is not updated: {noformat} select * from moved_issue_key ; id | old_issue_key | issue_id -------+---------------+---------- 10000 | MWK-1 | 10001 (1 row) {noformat} h3. 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: {noformat} select id from project where pkey = 'TECH'; id ------- 10001 (1 row) {noformat} # Update the issue to have the correct project: {noformat} update jiraissue set project = 10001 where id = 10001; UPDATE 1 {noformat} # 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. h3. Original Description {quote} 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. {quote}

    Atlassian JIRA | 2 years ago | Jesika DiGregorio
    java.lang.IllegalArgumentException: Passed List had more than one value.
  3. 0

    h3. 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. h3. 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. h3. 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). h3. 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. {noformat} 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] {noformat} See [^full_stack_trace] for more info. h3. 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: {noformat} 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) {noformat} And after: {noformat} 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) {noformat} The {{moved_issue_key}} table is not updated: {noformat} select * from moved_issue_key ; id | old_issue_key | issue_id -------+---------------+---------- 10000 | MWK-1 | 10001 (1 row) {noformat} h3. 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: {noformat} select id from project where pkey = 'TECH'; id ------- 10001 (1 row) {noformat} # Update the issue to have the correct project: {noformat} update jiraissue set project = 10001 where id = 10001; UPDATE 1 {noformat} # 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.

    Atlassian JIRA | 9 months ago | Ismael Jimoh [Atlassian]
    java.lang.IllegalArgumentException: Passed List had more than one value.
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    h3. 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. h3. 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. h3. 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). h3. 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. {noformat} 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] {noformat} See [^full_stack_trace] for more info. h3. 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: {noformat} 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) {noformat} And after: {noformat} 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) {noformat} The {{moved_issue_key}} table is not updated: {noformat} select * from moved_issue_key ; id | old_issue_key | issue_id -------+---------------+---------- 10000 | MWK-1 | 10001 (1 row) {noformat} h3. 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: {noformat} select id from project where pkey = 'TECH'; id ------- 10001 (1 row) {noformat} # Update the issue to have the correct project: {noformat} update jiraissue set project = 10001 where id = 10001; UPDATE 1 {noformat} # 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. h3. Original Description {quote} 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. {quote}

    Atlassian JIRA | 2 years ago | Jesika DiGregorio
    java.lang.IllegalArgumentException: Passed List had more than one value.

    Not finding the right solution?
    Take a tour to get the most out of Samebug.

    Tired of useless tips?

    Automated exception search integrated into your IDE

    Root Cause Analysis

    1. java.lang.IllegalArgumentException

      Passed List had more than one value.

      at org.ofbiz.core.entity.EntityUtil.getOnly()
    2. org.ofbiz.core
      EntityUtil.getOnly
      1. org.ofbiz.core.entity.EntityUtil.getOnly(EntityUtil.java:62)[entityengine-1.2.3.jar:?]
      1 frame
    3. com.atlassian.jira
      DefaultIssueService.getIssue
      1. com.atlassian.jira.issue.managers.DefaultIssueManager$IssueFinder.getIssueFromIssueEntityByProjectAndNumber(DefaultIssueManager.java:986)[DefaultIssueManager$IssueFinder.class:?]
      2. com.atlassian.jira.issue.managers.DefaultIssueManager$IssueFinder.getIssueFromIssueEntity(DefaultIssueManager.java:982)[DefaultIssueManager$IssueFinder.class:?]
      3. com.atlassian.jira.issue.managers.DefaultIssueManager$IssueFinder.getIssue(DefaultIssueManager.java:959)[DefaultIssueManager$IssueFinder.class:?]
      4. com.atlassian.jira.issue.managers.DefaultIssueManager.getIssue(DefaultIssueManager.java:140)[DefaultIssueManager.class:?]
      5. com.atlassian.jira.issue.managers.DefaultIssueManager.getIssueObject(DefaultIssueManager.java:340)[DefaultIssueManager.class:?]
      6. com.atlassian.jira.bc.issue.DefaultIssueService.getIssue(DefaultIssueService.java:170)[DefaultIssueService.class:?]
      6 frames
    4. Java RT
      Method.invoke
      1. sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[?:1.8.0_20]
      2. sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)[?:1.8.0_20]
      3. sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[?:1.8.0_20]
      4. java.lang.reflect.Method.invoke(Method.java:483)[?:1.8.0_20]
      4 frames