Automatic transitions triggered by Stash should allow more advanced conditions and actions

Background

In support of our common Agile (weekly) release workflow, we affix a "fixVersion" to any jira ticket branch merged to our common develop branch. To facilitate effective, manual regression testing (our system tests already completed on develop as a nightly process), we branch weekly from develop (Release-YYYYMMDD) and release weekly. Any test fail is either reverted, fixed, temporarily tolerated for immediate follow-up "next-day" fix, release-noted, or rolled back to last "clean" label on develop (last option... "baby with the bathwater"). Lastly, if changes are currently passing manual regression, we release to master on release day (all tickets transitioned to released state)

The Problem: "Automatability" of Setting "fix version"

We want to leverage Jira and Stash to do a couple of things:

1. After each pull request merge, we want to affix a (new or existing) "fix version" to the tickets being merged to develop. We've installed JJupin but the "destination branch" in the Jira automated transition is not visible to our post function. The transition logic is as follows: "If a pull request is merged and the destination branch is {{develop} then add "YYYYMMDD" (the "develop" scheduled release date) fix version to the ticket.
2. When a pull request is reverted (please implement STASH-3218?), remove any YYYYMMDD fix version from the ticket and reopen the jira ticket.

What we need?

1. Add more "pull request" data to the automated Jira transitions triggered by stash PRs such as "source branch", "destination branch" etc and make them visible to Jira post function actions. Greater PR data visibility allows for better, more customized decisions in the jira ticket workflow.