Available Macros on Post Function "Update Issue custom field"

[Luiz-F Ferreira]

Hi to all,

I'm trying to implement some post functions for handling some custom_fields values, and I believe it's the "vanilla" jira version of post function, not a marketplace add-on.

There is a "help box" providing some details and warnings about applicable values, and a note that points to 2 available macros for use (%%CURRENT_USER%% and %%CURRENT_DATETIME%%).

My question here is pretty simple, as I just haven't found anything related to that on docs (maybe have missed).

What are the currently available macros? Are there any other? If yes, where are they listed? Are smart-values are supported in post-functions?

Is there a way to copy the issuekey with the "update issue Custom Field" post-function?

Thank you in advance!

Luiz Fernando L R Ferreira

[Mykenna Cepek · Accepted solution]

Wow, you're right. As far as I can find, the "note" you see when configuring the "Update issue custom field" post function seems to be the entirety of the documentation for those "macros".

While it makes sense to try to use a post function for this, have you considered using Jira Automation instead?

It's fairly easy to use (start here if you are new to it).

For your case, it sounds like you'd want to start your automation rule with an "Issue Transitioned" trigger, indicating the "to status" that matches the destination status from the workflow step (where you were trying to use the post function).

Then add an "Edit Issue" action to your rule, select your custom field, and for the value use:

{{issue.key}}

which is the Automation smart value for the Jira key of the issue that triggered the rule.

Publish the rule, change the "Rule Details" so that the "Scope" is just the one project where you will first test the rule. Now you can transition an issue and see if it works as expected.

Inspect the "Audit Log" of for the rule if things don't work as expected.

Hope that helps. Workflow post functions can help with some simple things. But I end up using Automation for anything even slightly complex.

[Luiz-F Ferreira]

Thank you for the answer, Mykenna!

This operation was configured on Jira Automation right before I wrote the question and I was trying turn that on a Post Function Operation due to synchronization issues with a marketplace extension (Salesforce Connector for Jira).

During the transition there is a "push to Salesforce" step (Post Function), and I wanted to guarantee the custom field was properly filled! If I write on the custom field using Jira Automation the system will generate a second "push to salesforce" operation when the automation finishes the "edit Issue" step, and these two triggers on a short interval are causing some sync issues :)

I'm in contact with the Extension Developer as it would be far easier to send the "issuekey" field directly, but for some reason it isn't work on my project (and it should, according to documentation)

I'll mark your answer as the "Accepted" as it is another confirmation that there are no other documentation on these "Macros" and I believe it may help others due to the very well explained introduction to Jira Automation.

Thank you very much, once more!

Luiz Fernando L R Ferreira

[Mykenna Cepek]

I'm a little confused by your explanation, since a Post Function should only run when an issue transitions into that particular state. Editing a custom field on an issue (using automation or otherwise) shouldn't trigger a workflow post function.

I'm probably just not understanding a detail of your implementation.

- - - - - - -

One other thought: by using two transitions, you could decouple the two operations you are attempting:

• the first status transition would trigger automation, which would:
  • update the custom field
  • transition the issue to the next status
• the second status transition would fire the post function (just once)

Plenty of concerns here about user visibility and access to both statuses. You probably wouldn't want users to even accidentally transition directly to the second status, and miss the first one. But maybe it is a workaround to experiment with?

[Luiz-F Ferreira]

Sorry about the confusion, I'll try to explain it better, as the second "push to salesforce" is not a Post Function triggered by a transition, but triggered by a PlugIn configuration :)

The Plugin does have 2 options to synchronize the fields from the Jira Issue to the Salesforce Object. There is the "Auto-Push" configuration that sends an update to salesforce everytime a mapped custom field is updated (in my case, the issuekey mirror field). And the second option would be the "Push to Salesforce" Post Function, that "forces" an update on all mapped fields during the transition.

Currently I have both configuration set, as there are some projects that use the same connector and most of them doesn't have the Post Function properly configured yet and rely entirely on the "Auto Push" configuration. (Killing the "Auto Push" would kill other projects' integration)

As I talked to the plugin support, they said it is known that close requests to the same object may cause some errors, and in my case occurs the following:

      1- Issue is created and triggers the "Created" transition -> some fields are filled with post functions and then pushed to Salesforce (with the post function). The transition Ends and triggers the "Issue Created" Event.

      2- The event fired on the end of the "Created" transition triggers the automation to fill the custom field. -> The edited custom field triggers the "Auto Push" configuration, creating a second request for the plugin in a close interval with different information on said custom field. (On first "push" it was empty (post function), on second it contains the issuekey (auto push triggered by "Edit Issue" Automation))

Outcome: sometimes the result on salesforce is not the last request (issuekey), but the first "empty" information that was pushed by the post function. (My guess is that it may be caused by some sort of delay on salesforce API update request, and the delay causes the desync)

I hope I have made things a bit clearer than before, but the "Post Function Workaround" was an attempt to solve an synchronization issue with the plugin and Salesforce. :D

[Mykenna Cepek]

A few other thoughts to consider for further experimentation:

• Remember that the "Edit issue" action can update multiple fields at once. I'm not sure if that might help avoid triggering your "push to SalesForce" operation multiple times, but it might if you are using multiple "Edit issue" actions in a row.
   
• Separating things out into multiple ("chained") rules might be helpful too. Look for the checkbox to enable rule triggering from other rules. Normally this is off, but for chained rules, you want the later rule(s) to have that enabled. Use it sparingly and carefully! But this might help in combination with my next bullet...
   
• Would it help to have a conditional early in your rules to identify who is updating the rule causing the rule to be triggered? For example, it might be helpful to detect that the rule was triggered by an edit from the SalesForce add-on, and your rule could act differently. This assumes the add-on leverages a "service user" that the rule can identify as the "rule initiator". Use the following Smart Value to see "who" triggered the rule:

{{initiator.displayName}}