I am using a groovy listener to update a field with the following code snippet
MutableIssue issue = event.issue as MutableIssue log.setLevel(org.apache.log4j.Level.DEBUG) //Get current state of the indexer (usually false/disabled) def wasIndexing = ImportUtils.indexIssues; ImportUtils.indexIssues = true; // define some generic stuff used by all CustomField cfID = cfm.getCustomFieldObjectByName("GlobalID") def issueM = cm.getInstance().getIssueManager(); def indexM = cm.getIndexManager(); //============================================================================== // Set the user to the admin user to get admin rights def admin_user = cm.getUserUtil().getUser("admin") cm.getJiraAuthenticationContext().setLoggedInUser(admin_user) ... (more code but no edits to issue )
issueWatermark = issueM.getIssueObject("ADMIN-1") def vNextID = issueWatermark.getCustomFieldValue(cfID) //-------------------------------------------------------------------------------------- // Assign ID to issue IssueInputParameters setIDParameters = new IssueInputParametersImpl(); setIDParameters.addCustomFieldValue(cfSonicsID.getId(), vNextID) def updateIDValidationResult = issueService.validateUpdate(admin_user, issue.getLong("id"), setIDParameters); if (updateIDValidationResult.isValid()) { def updateIDResult = issueService.update(admin_user, updateIDValidationResult, EventDispatchOption.DO_NOT_DISPATCH, false); indexM.reIndex(updateIDResult.getIssue()) log.debug "Setting ID for issue "+issue.getKey()+" to "+vNextID.toString() } else {log.debug "no ID update on "+issue.getKey();} }
Line number 31 passes for a "Task" type but fails for a "sub-task". The admin_user is in the admin group, so he shouldn't have any permission problems. From the log command, I can see that the key is for the right issue (e.g. not the parent issue). What could possibly cause it to not work on sub-task creation?
I do a reIndex on a different issue in the missing code (...). Perhaps, that is messing me up some how.
George
the validationResult has an errorCollection which will have details on why it failed. Try printing the details in it.
Thanks for the suggestion. I added:
updateIDValidationResult.errorCollection.errors.each {log?.error "Error: $it"}
It printed:
Error: issuetype=Issue type is a sub-task but parent issue key or id not specified.
I'm a little confused by the message. Do I need to determine if the issue that I'm trying to do this to is a subtask and if so, add
setIDParameters.setIssueTypeId(issueSubtaskTypeId);
George
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I haven't seen an option to set parentId or key in the Input parameters. I don't know if you can use FieldValuesHolder. Try IssueManager and see if that helps.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I've done a little more testing. This is done in a groovy scriptrunnner, which was being run on issue Created. If I change it to Issue Commented, and comment the issue, the code works as expected. Now I need to figure out why issue Created works differently than Issue Commented.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
There has been some questions on here recently about negative interactions when changing an issue in a listener and the AutoWatch listener... sounds related. Personally I could not reproduce the fix with disabling the autowatch listener.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I turned off AutoWatch for the admin user, but that did nothing different.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
instead of using the IssueInoputParameter technique, I used the setCustomField technique and it works now.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Looks like you can use issueInputParameters.setRetainExistingValuesWhenParameterNotProvided(true, true) to tell JIRA not to try to validate the issue type. Seems to work
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Which is line 31? Can you log the updateIDValidationResult, what does that show ? It should have methods like getErrors or getErrorCollection to find out what went wrong, but the toString() result may well have that.
Is the custom field on the screen for the sub-task?
None of the reindex code should be necessary btw.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.