Post function to execute delayed transition
Hi Fidel,
I'm having a problem with executing a delayed transition in my workflow. I've created a post function to check the value of a select list, then if the required value is selected the issue will be transitioned to the "Approved" status. When I create a new issue the post function does not fire.
I've used this type of post function in other workflows without any issue. Is there anything obvious that I'm doing wrong here?
Thanks, Weston
Comments (19)
-
repo owner -
reporter Hi Fidel,
In this case, there is a status after the Create Transition called Awaiting Manager Approval, from there the issue can be transitioned to Approved. There are no conditions or validators attached to this transition.
I've also noticed that this post function isn't working in another project workflow. This has been working fine in our Test environment until recently. I recently updated the add-on to the latest version, so I'm not sure if this is the cause of the issue. Other post functions seem to be working fine.
Here is the post function of this other workflow, along with the conditions and validators. No changes have been made to this workflow since it was last working.
-
repo owner Hi @WestonR,
The problem could be that the setting rule is not being matched. We can do the following tests:
-
Select New comment as target field, instead of "Execute transition (delayed execution)". Now we expect that an automatic comment with the name of the transition we want to execute.
-
We can use
(.*)
in the conditional part of the setting rule. This will ensure that the setting rule is matched. Example:(.*)Auto Approved
.
Please, try one or both tests, and share with me the results obtained.
-
-
reporter Thanks Fidel, I'll give this a try now.
Thanks, Weston
-
reporter Fidel, I tried both steps you suggested separately and the post function fired correctly each time.
It seems that the setting rule is working.
-
repo owner Please, try using "Issue status (delayed writing)" as target field, and use the status name instead of the transition name.
-
reporter I tried using this field instead, and the status name is the same as the transition name. Unfortunately, I got the same results.
I should also mention that I've noticed another post function that was originally working no longer works. This post function sets the Customer Request Type when a ticket is created using the Create button instead of using the Customer Portal. It was working until recently and no changes have been made to the post function, conditions, or validators. I was able to confirm that I have the right Customer Request Type ID used in the post function. This type of post functions is also present in other projects/workflows and is no longer working.
These issues seem to have come up since that latest update to the add-on in our Test environment. Since it doesn't look like other people are experiencing this behavior, I'm wondering if it's necessary to just remove and re-install the add-on. Is there a way to back up the configuration first?
-
repo owner Hi @WestonR,
It's very extrange. I haven't received any problem reports like those you are describing for version 2.2.40.
Please, try reinstalling version 2.2.39. To do it you should:
- Download .jar file for version 2.2.39.
- Uninstall version 2.2.40.
- Upload .jar file for version 2.2.39.
Please, let me know whether it solves your problem.
-
reporter Okay, I'll give this a try.
Will I lose my post function configurations by uninstalling this add-on?
-
repo owner No, you won't lose any configuration in your workflows.
-
reporter Hi Fidel,
Re-installing the add-on has fixed the problematic post functions across all other projects that are using them. I'm still having problems with my original post function, and I've come across some strange behavior with it. I created an additional status and transition called Test, and I also created a new post function that executes a transition to the Test status. The first post function doesn't fire, but the second post function and the one I've been having trouble with now works.
I've tried reordering my post functions to get this working, but if I change the first post function or re-order them, the one to transition to Approved doesn't work. Very strange!
-
repo owner Was the problem solved after downgrading to version 2.2.39?
Please, try using selecting New comment at post-function 2, so that a comment
Test
will be created. I want to find out whether post-function 3 keeps working, or stop working.Can you, please, try reinstalling version 2.2.40 and check whether the post-functions keeps working, or fails again?
Do you have any custom listeners in your JIRA instance?
Can you, please, send me your server's log file to support@workflowarts.com?
-
reporter Hi Fidel,
Downgrading to 2.2.39 fixed the various post functions across all projects. I was also able to upgrade to version 2.2.40 and that didn't break anything.
In my one problematic workflow, I switched over to using New comment in post-function 2. It added the comment "Test" to the new ticket I created, but post-function 3 wouldn't work. After switching post-function 2 back to its original settings post-function 3 was working again.
As far as I know, there aren't any custom listeners in this instance. Here is the current list.
I also emailed you the server's log file. Let me know if that's the right file or not.
Thanks, Weston
-
repo owner Hi @WestonR,
I'm reproducing the problem. I don't know yet the cause.
For the moment, it seems that the problem happens only in "Create Issue" transitions when only one JWT post-function is used. If you use more than one post-function (e.g., one for transitioning issue, and the other one is for setting issue Description), the problem doesn't happen.
-
repo owner Hi @WestonR,
By default delayed transition executions happen 500 ms after the transition where post-function is inserted ends. It seems that when delayed transition execution is ordered from Create Issue transition in a JSD project a longer delay is required.
Fortunately, JWT allows to add an extra parameter for setting a custom delay. Please, try appending
: {delay=1000}
(i.e, 1000 ms = 1 s) after the transition name written into Execute transition (delayed execution).Examples:
Test : {delay=1000}
or
(Imported)Approved : {delay=1000}
Please, let me know if it solves the problem.
BTW, are you experiencing the problem in a JSD project?
-
reporter Fidel,
Setting the post function to (Imported)Approved : {delay=1000} worked! The post function is now working correctly. Also, we were experiencing this issue in a JSD project.
Going forward, should I use a delay on these types of post functions?
Thank you very much for your help with this issue, it was a tricky one!
Weston
-
repo owner The 500 ms default delay works well in 99% of the situations, but in same cases you may encounter problems. It seems that auto-transitioning an issue in a JSD project just after the issue has been created (transition Create Issue) is one of those strange cases.
The need of a custom delay may also depend on the particular characteristics of the server where JIRA is running.
-
repo owner - changed status to resolved
-
Hi,
Do you know if this is still an issue with the newer releases of Jira Service Desk -
JIRA Service Desk 3.16.2 & Jira Software 7.13.2
JWT Version: 2.4.12Should we still set the delay to 1000?
- Log in to comment
Hi @WestonR,
In order to transition the issue to status "Approved" using "Issue status" or "Issue status (delayed status)" virtual fields, a transition from initial status to "Approved" status should exist, and its conditions and validations should be satisfied.
In case you don't have the transition above described, you can create one, and hide it to JIRA users using "Transition is triggered by JIRA Workflow Toolbox post-function" condition.