Move Issue from Type A to Type B fails with error

Nadav Eckstein September 22, 2020

Hi,

We are getting an error when trying to move Issue from one type to another and set "Feature Link" field (Single Issue Picker, Scripted field) during the move. We suspect the issue is with this field since if we don't set it during the move but rather before or after, it works fine.

We get an error screen (500) and this error logs:

Technical details
Log's referral number: c6894a63-8986-4433-98d4-84767b67f4aa

Cause
Referer URL: http://vm-jira.sio.lab.emc.com:8080/secure/MoveIssueUpdateFields!default.jspa?id=101016&assignee=null

Assertion failed:

assert issue.projectId // Missing projectId in fieldValues
| |
| null
com.atlassian.jira.issue.IssueImpl@9e5ffcc (toString() == null)
Assertion failed:

assert issue.projectId // Missing projectId in fieldValues
| |
| null
com.atlassian.jira.issue.IssueImpl@9e5ffcc (toString() == null)

at org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:415) [?:?]
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:670) [?:?]
at com.onresolve.scriptrunner.canned.jira.fields.editable.TemporaryIssueService.populateForCreation(TemporaryIssueService.groovy:78) [?:?]
at com.onresolve.scriptrunner.canned.jira.fields.editable.TemporaryIssueService$populateForCreation.call(Unknown Source) [?:?]
at com.onresolve.scriptrunner.runner.field.IssueParametersCapturingImmutableCustomField.validateParams(IssueParametersCapturingImmutableCustomField.groovy:88) [?:?]
at com.atlassian.jira.web.action.issue.MoveIssueUpdateFields.doValidation(MoveIssueUpdateFields.java:192) [classes/:?]
at webwork.action.ActionSupport.validate(ActionSupport.java:391) [webwork-1.4-atlassian-30.jar:?]
at webwork.action.ActionSupport.execute(ActionSupport.java:162) [webwork-1.4-atlassian-30.jar:?]
at com.atlassian.jira.action.JiraActionSupport.execute(JiraActionSupport.java:63) [jira-api-8.5.5.jar:?]

.

.

.

The error message is longer with many more lines but I can't add it due to the message length limitation.

 

Thanks.

2 answers

1 vote
Fabio Racobaldo _Herzum_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
October 13, 2020

Hi @Nadav Eckstein ,

I had the same issue on my environment. It's a bug due to Script Runner version. Please upgrade this plugin to 6.11 version in order to fix this issue.

Hope this helps,

Fabio

Silvana Tieko Takara February 11, 2021

Hi, Fabio.

I had the same issue on my environment. I upgraded the Script Runner plugin, that was in version 6.9.1 to version 6.19.0 and the problem was fixed.

The problem is a bug, see this link https://productsupport.adaptavist.com/browse/SRJIRA-4688

Thanks!

Silvana

0 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
September 23, 2020

The first few lines of a log are generally enough to get us well into debugging.

Exactly as you suspect, I suspect the script as well.  But without seeing the script, we cannot do a lot more than tell you that there's something not quite right in its assertions.

Nadav Eckstein September 23, 2020

Thanks for the response @Nic Brough -Adaptavist-

It doesn't really have a script, this is an issue picker script field.

So all I did is created it through Admin -> Fields and chose the name and the JQL (which is really simple: Type=Feature).

In general, the fields works fine, it only breaks the move between types if the field is set in the move screen.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
September 27, 2020

Ah, I see.  The problem here is that your move process is trying to change something that is unknown at the time of the move.  Jira can't know what the scripted field might need as valid data because the move process has not been written to understand how that field type works (theoretically, it could, but it's a 3rd party field that Atlassian don't have any control over, other than hoping the partner who wrote it will actually talk to them if it changes, and it would be a huge piece to support all the partner provided fields fairly, so they simply don't)

I'm afraid "don't try to change it during a move" is the only way to address this one.

Suggest an answer

Log in or Sign up to answer