Transition related issue in another project from workflow post function

[Geert Graat]

Hi,

I use the Script Runner to transition a related issue when an issue is resolved. This worked fine when both issues were in the same project (issues have different workflows). Now I created the related issue in another project and suddenly it does not work anymore. I have tried the built in script (https://jamieechlin.atlassian.net/wiki/display/GRV/Built-in%20Scripts#Built-InScripts-Fast-tracktransitionanissue) and a custom script, both complain that the specified workflow ID does not exist.

The workflow of the related issue has not changed however (and I double checked the ID and it is correct). It seems that the fact that the workflow is in another project is in the way. What do I need to do to resolve this?

log from built-in script

2014-09-22 11:12:47,858 Thread-206 ERROR g.graat 672x3704x1 166je96 172.24.1.30 /secure/CommentAssignIssue.jspa [canned.jira.utils.WorkflowUtils] Errors: {}
Error Messages: [The workflow operation with action id '81' does not exist in the workflow.]
2014-09-22 11:12:47,858 Thread-206 ERROR g.graat 672x3704x1 166je96 172.24.1.30 /secure/CommentAssignIssue.jspa [canned.jira.utils.WorkflowUtils] Not attmpting transition

log from custom script

2014-09-22 10:53:40,871 http-bio-8080-exec-21 ERROR g.graat 653x3307x1 166je96 172.24.1.35 /secure/CommentAssignIssue.jspa [scriptrunner.jira.workflow.ScriptWorkflowFunction] Script function failed on issue: BQ-2368, actionId: 5, file: <inline script>
java.lang.IllegalArgumentException: No workflow action with id '81' available for issue CSD-3
at com.atlassian.jira.workflow.WorkflowTransitionUtilImpl.getActionDescriptor(WorkflowTransitionUtilImpl.java:151)
at com.atlassian.jira.workflow.WorkflowTransitionUtilImpl.hasScreen(WorkflowTransitionUtilImpl.java:338)
at com.atlassian.jira.workflow.WorkflowTransitionUtilImpl.progress(WorkflowTransitionUtilImpl.java:312)
at com.atlassian.jira.workflow.WorkflowTransitionUtil$progress$2.call(Unknown Source)
at Script2.run(Script2.groovy:38)

[Geert Graat · Accepted solution]

Ok, finally figured it out. It turned out that it was an authorization issue. Although the workflow action id does exist, the user that tried to execute it is not allowed to do so. What I was trying to do was update an issue in a Service Desk project as a collaborator, and collaborators are not allowed to transition service desk issue. If I execute the same as an agent, everything works fine.

It turns out that Service Desk blocks executing transitions as another user, see https://answers.atlassian.com/questions/8628385

[Tarun Sapra]

HI Geert, so as the final solution you used your custom script or tweaked the built-in script?

[Geert Graat]

Hi, just changed the answer, as it still does not work. I use my own custom script, but I still have not got it to work.

[Tarun Sapra]

HI Geert, Thanks for updating, I avoid writing custom scripts as external groovy files since things can get messed up quickly in lasrge JIRA instances and only in the new version of script runner I can write custom-scripts in the post-function itself, Thus right now I am exploring the possibility of firing a custom event when the issuue is closed and using the built-in "Fast Track transition" listener to handle that even and close the issue and put an appropriate comment.

[Tarun Sapra]

Ok, I have found a much better way to implement this functionality, in the script runner plugin there is a "built-in" script feature which would run on certain set of issues returned as result by a JQL, instead of writing a dedicated groovy script I have decided to use Escalation service to close all the linkedIssue of a certain issueType using a escalation service which runs once per day.

[Geert Graat]

Hi Tarun, thanks for the update. Sounds like something I am going to try when I have some time available.

[Geert Graat]

Hi Jamie, Thank you for so rapidly looking into this. Good to know that fast track only works on the current issue. I did use my own custom script, but then turned to the built-in script once I could not get it to work. The script definitely has some assumptions,which allows me to take some shortcuts. The issue that is currently transitioned is created by the related issue with another script when it transitions to a certain state, using this predefined relation. That is why I check on the relation type and status of the related issue. The custom script already logs this: No workflow action with id '81' available for issue CSD-3 I checked and double checked the workflow and it absolutely does have an action with ID 81. The script worked absolutely fine until I moved one of the issuetype + workflow to another project. This did not affect the workflow IDs.

[JamieA]

Fast-track only works on the current issue... so it is able to show a list of actions for the appropriate workflow (the one that is being edited). All other things being equal, I would say that 81 is not a valid action for that state in that workflow. Also this doesn't seem that safe - you can link an issue to any other issue - just because it has status 10019 it doesn't mean it will have action 81.... Can you log the issue keys if the issues you are updating, so you can verify that 81 really is valid for all of them.

[Geert Graat]

Hi Jamie, See the code below. The first part is the condition when to execute this, then the part to transition the issue, in which the action ID of the workflow is set, is executed. This is the action ID of the workflow that is associated with the related issue. When I configure the fast-track transition issue built in script, I select the same ID. There is no transition with the same name btw. import com.atlassian.jira.component.ComponentAccessor import com.atlassian.jira.security.JiraAuthenticationContext import com.atlassian.jira.workflow.WorkflowTransitionUtil; import com.atlassian.jira.workflow.WorkflowTransitionUtilImpl; import com.atlassian.jira.util.JiraUtils; import com.atlassian.jira.issue.link.IssueLinkManager import com.atlassian.jira.issue.comments.CommentManager def compAccessor = new ComponentAccessor() // retrieve the inward links for the issue (Support Request = source, Bug = destination) def linkManager = compAccessor.getIssueLinkManager() def links = linkManager.getInwardLinks(issue.getId()) for (link in links) {     if (link.getIssueLinkType().getId() == 10500 as Long) {     // since the issue was created by the relatedIssue, simply assume here that the first link is the correct one         def relatedIssue = link.getSourceObject()         // check that related issue status is To Dev, otherwise do nothing         def status = relatedIssue.getStatusObject().getSimpleStatus().getId()         if (status == "10019") {             // get the user who resolved the bug             def authContext = compAccessor.getJiraAuthenticationContext()             def userKey = authContext.getUser().getKey()                           // create the workflow action to Dev Ready             def workflowTransitionUtil = ( WorkflowTransitionUtil ) JiraUtils.loadComponent( WorkflowTransitionUtilImpl.class )             workflowTransitionUtil.setIssue(relatedIssue)             workflowTransitionUtil.setUserkey(userKey)             workflowTransitionUtil.setAction(81)                       // add a comment so support sees what triggered the status change (only visible on Developer [10001] level)             def commentManager = compAccessor.getCommentManager()             String comment = "[auto-comment] Bug "+ issue.getKey() +" causing this support request has been resolved."             commentManager.create(relatedIssue, userKey, comment, null, 10001 as Long, true)                           // validate and transition issue             workflowTransitionUtil.validate()             workflowTransitionUtil.progress()         }     } }

[JamieA]

Can you post your code (the simplest example that demonstrates the problem) ? Even though the actions may have the same name they will have different action IDs, and that's what it's complaining about.