I’m trying to have Zendesk ticket status to change to On-hold with the Rules. I can get the other statuses to work but on-hold just isn’t working with any combination. Is it supported by Exalate at all?
/*
Status Synchronization
Sync status according to the mapping [remote issue status: local issue status]
If statuses are the same on both sides don’t include them in the mapping
*/
def statusMapping = [
// Jira issue status \<\-\> Zendesk ticket status
// How to change the pending to on\-hold status instead?
"Backlog" : "pending",
"In Progress" : "pending",
"Done" : "open"
]
In Zendesk you can have normally following statuses for the tickets:
New
Open
Pending
Solved
Closed
In addition you can enable from the settings “On-Hold” status. That one I’m having trouble getting to work in a way that the connection doesn’t crash.
I’ll try if that change works
-Petri
Comments:
Petri Pihlajamaa commented on 04 November 2020
Results error with following setup. Also tried with “onhold” variation
/*
Status Synchronization
Sync status according to the mapping [remote issue status: local issue status]
If statuses are the same on both sides don’t include them in the mapping
*/
def statusMapping = [
Error Detail Message: Script error for issue 16604. Details: Cannot cast object ‘on-hold’ with class ‘java.lang.String’ to class ‘com.exalate.api.domain.hubobject.v1_2.IHubStatus’. Error line: Script16.groovy:37
Error Stack Trace: com.exalate.api.exception.script.ChangeProcessorException: Script error for issue 16604. Details: Cannot cast object ‘on-hold’ with class ‘java.lang.String’ to class ‘com.exalate.api.domain.hubobject.v1_2.IHubStatus’. Error line: Script16.groovy:37 at com.exalate.error.services.ScriptExceptionCategoryService$.wrapAsChangeProcessorException(ScriptExceptionCategoryService.scala:58) at com.exalate.replication.services.processor.ChangeIssueProcessor$$anonfun$1.applyOrElse(ChangeIssueProcessor.scala:114) at com.exalate.replication.services.processor.ChangeIssueProcessor$$anonfun$1.applyOrElse(ChangeIssueProcessor.scala:100) at scala.runtime.AbstractPartialFunction.apply(AbstractPartialFunction.scala:36) at scala.util.Failure.recoverWith(Try.scala:203) at com.exalate.replication.services.processor.ChangeIssueProcessor.com$exalate$replication$services$processor$ChangeIssueProcessor$$executeScriptRules(ChangeIssueProcessor.scala:100) at com.exalate.replication.services.processor.ChangeIssueProcessor$$anonfun$changeIssue$1.apply(ChangeIssueProcessor.scala:79) at com.exalate.replication.services.processor.ChangeIssueProcessor$$anonfun$changeIssue$1.apply(ChangeIssueProcessor.scala:51) at scala.concurrent.Future$$anonfun$flatMap$1.apply(Future.scala:253) at scala.concurrent.Future$$anonfun$flatMap$1.apply(Future.scala:251) at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:32) at scala.concurrent.impl.ExecutionContextImpl$AdaptedForkJoinTask.exec(ExecutionContextImpl.scala:121) at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260) at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339) at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979) at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107) Caused by: com.exalate.api.exception.script.ScriptException: Cannot cast object ‘on-hold’ with class ‘java.lang.String’ to class ‘com.exalate.api.domain.hubobject.v1_2.IHubStatus’. Error line: Script16.groovy:37 at com.exalate.error.services.ScriptExceptionCategoryService.categorizeProcessorAndIssueTrackerExceptionsIntoScriptExceptions(ScriptExceptionCategoryService.scala:36) at com.exalate.processor.ExalateProcessor.executeProcessor(ExalateProcessor.java:48) at com.exalate.replication.services.processor.ChangeIssueProcessor$$anonfun$4.apply(ChangeIssueProcessor.scala:98) at scala.util.Try$.apply(Try.scala:192) at com.exalate.replication.services.processor.ChangeIssueProcessor.com$exalate$replication$services$processor$ChangeIssueProcessor$$executeScriptRules(ChangeIssueProcessor.scala:96) … 10 more Caused by: javax.script.ScriptException: javax.script.ScriptException: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object ‘on-hold’ with class ‘java.lang.String’ to class ‘com.exalate.api.domain.hubobject.v1_2.IHubStatus’ at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:151) at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264) at com.exalate.processor.ExalateProcessor.execute(ExalateProcessor.java:73) at com.exalate.processor.ExalateProcessor.executeProcessor(ExalateProcessor.java:46) … 13 more Caused by: javax.script.ScriptException: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object ‘on-hold’ with class ‘java.lang.String’ to class ‘com.exalate.api.domain.hubobject.v1_2.IHubStatus’ at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:348) at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:145) … 16 more Caused by: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object ‘on-hold’ with class ‘java.lang.String’ to class ‘com.exalate.api.domain.hubobject.v1_2.IHubStatus’ at org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnSAM(DefaultTypeTransformation.java:392) at org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnNumber(DefaultTypeTransformation.java:306) at org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:227) at groovy.lang.MetaClassImpl.setProperty(MetaClassImpl.java:2652) at groovy.lang.MetaClassImpl.setProperty(MetaClassImpl.java:3702) at org.codehaus.groovy.runtime.InvokerHelper.setProperty(InvokerHelper.java:195) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setProperty(ScriptBytecodeAdapter.java:482) at Script16.run(Script16.groovy:37) at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:345) … 17 more
Francis Martens (Exalate) commented on 05 November 2020
My wrong …
issue.setStatus(statusName)
Will avoid the error you see.
Petri Pihlajamaa commented on 05 November 2020
Francis Martens (Exalate)
The errors changed. The code works with others statuses but “onhold” or “on-hold” results in this error
Error Detail Message:
Status cannot be blank
services.exception.TicketErrorCollectionException: Status cannot be blank at services.node.client.ZendeskClient.services$node$client$ZendeskClient$$filterResponse(ZendeskClient.scala:706) at services.node.client.ZendeskClient$$anonfun$updateIssue$1$$anonfun$apply$134$$anonfun$apply$135.apply(ZendeskClient.scala:689) at services.node.client.ZendeskClient$$anonfun$updateIssue$1$$anonfun$apply$134$$anonfun$apply$135.apply(ZendeskClient.scala:689) at scala.concurrent.Future$$anonfun$flatMap$1.apply(Future.scala:253) at scala.concurrent.Future$$anonfun$flatMap$1.apply(Future.scala:251) at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:32) at akka.dispatch.BatchingExecutor$AbstractBatch.processBatch(BatchingExecutor.scala:55) at akka.dispatch.BatchingExecutor$BlockableBatch$$anonfun$run$1.apply$mcV$sp(BatchingExecutor.scala:91) at akka.dispatch.BatchingExecutor$BlockableBatch$$anonfun$run$1.apply(BatchingExecutor.scala:91) at akka.dispatch.BatchingExecutor$BlockableBatch$$anonfun$run$1.apply(BatchingExecutor.scala:91) at scala.concurrent.BlockContext$.withBlockContext(BlockContext.scala:72) at akka.dispatch.BatchingExecutor$BlockableBatch.run(BatchingExecutor.scala:90) at akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:39) at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:415) at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260) at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339) at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979) at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
Francis Martens (Exalate) commented on 05 November 2020
that status is not found then.
Please find out the correct name
Petri Pihlajamaa commented on 05 November 2020
Francis Martens (Exalate) Where can I find this as this is something inside Exalate or how it communicates with Zendesk?
Francis Martens (Exalate) commented on 05 November 2020
This is not something inside Exalate. It looks like the status is custom made and might have another ‘internal’ name. Do you work with a Zendesk partner for the configuration of your environment - can you ask them to assist. They are in a much better position then we are.
Petri Pihlajamaa commented on 05 November 2020
The On-Hold Status is a normal Zendesk status that can be enabled in the system. Could you reference as to what to ask from Zendesk if I reach out to them?
Francis Martens (Exalate) commented on 05 November 2020
If you add
Zendesk - outgoing sync
throw new Exception("Status - ${issue.status.properties}")
And sync a ticket, you will find out that the name of the status is hold
Status -
