Automation: When a branch is created, move to In Progress and assign the branch creator

[Josh Williams]

So we just spun up a new environment, I went to define my automated workflows and was presented with a "Hold up, triggers will be deprecated soon, use our new automations".

I'll bite. So I check them out - pretty intuitive.

But there are a few flows that I have found impossible:

Basically - any flow that involves assigning the user that [created a branch, created a PR] cannot be used.

Am I just missing it? Where is this option? Here is what I've tried:

Trigger When: Branch Created

Status Equals: To Do

Then: Transition the issue to IN PROGRESS, 

And: Assign the issue to (here are all the things I've tried):

  Automatic (this does nothing)

  User who triggered the event (this assigns it to the Automation Jira User)

I also tried just setting the field in the "Then: Transition the issue to IN PROGRESS" to "Automatic" and "User who triggered this event" <-- the same thing happens (either nothing, or it gets assigned to the "Automation User"

I also tried modifying the main Rule Details, changing the Actor from "Automation for Jira" to "User who triggered this event" but it gave me all kinds of validation errors:

"When security restrictions prevent running as the 'User who triggered the event', the actor will be 'Automation for Jira' instead.

Selecting an actor other than the 'Automation for Jira' user may cause other rules to be triggered by this rule, even if 'Allow rule trigger' isn't enabled"

and "The selected trigger requires the actor to be set to a user."

This was so simple with workflows triggers - it just assigned it to the user who created the branch or PR.

How do I do this now?

Just found this duplicate: https://community.atlassian.com/t5/Jira-Software-questions/How-to-change-Assignee-with-Automation-using-GitHub-cloud/qaq-p/1565258

[Oliver CENTENO · Accepted solution]

Hello all,

I had the same problem, the issue is never assigned no matter what you configure there.

Speaking with @Petter Gonçalves he confirmed that this is because the information is not sent within the event, so forget about it.

Nonetheless, he provided an idea for a workaround: Get the user from Bitbucket.

The first proposal was to call the Bitbucket API, but there you can only see the commit where the branch is created, and thus no trustworthy info can be obtained of the user who created the branch.

But I figured out a way to workaround the problem.

In Bitbucket we can create a webhook for the repo:push event. This even is very versatile and is triggered when new commits are added but also when a branch is created and/or deleted.

This is calling a Jira Automation listening to the same webhook URL, and posts a JSON payload containing:

a) the change (old and new status of the branch)

b) the actor (the user who created the branch)

Provided that the branch name contains an Issue ID, we can extract it (eg):

issuekey = {{webhookData.push.changes.new.name.match("([A-Z0-9]{2,4}-[1-9][0-9]*)")}}

And we can find the user account in {{webhookData.actor.account_id}}

---

Warning: In my case assigning the user directly gave problems so I used the "More Options" > "Addition fields" section of the transition:

{
  "fields": {
    "assignee": {{webhookData.actor.account_id.asJsonObject("id")}}
  }
} 

---

Warning: The action of creating a new branch sends a payload that contains push.changes.old as empty (null), thus it is good to add a condition to filter the requests.

[Navya Krishna Dubbala]

Hi @Oliver CENTENO 

Could you please share the steps for GitHUb webhook as well, also screenshot content doesn't show full information, if possible could you post all screenshots content non-secure data.

[Petter Gonçalves]

Hello @Josh Williams

Thank you for reaching out.

Indeed, the branch creator or any other users who triggered DevOps events can not be retrieved in Jira automation, so I created the following bug to report this behavior:

The option "User who triggered the event" does not work for Branch created trigger in Jira automation 

Feel free to vote and watch the bug to increase its priority and also receive notifications about any updates.

Additionally, it is a known problem that branch, PRs or Commit users can not be referenced in Jira, even when using workflow triggers (see JSWCLOUD-16862). To achieve this option, our Automation devs are developing new Smart values to properly reference the users linked to DevOps integrations:

Add support for user-based smart values for DevOps automation triggers 

Let us know if you have any questions.

[Josh Williams]

Thank you.

I left a comment that a potential workaround would be to continue using the old trigger system and hope that you don't deprecate triggers before this bug is fixed.

[Petter Gonçalves]

Hey Josh, 

Could you please confirm to us what do you mean by "Old Trigger System"? Are you meaning the Workflow triggers that can be added to transitions?

If that's what do you mean, I'm afraid it does not work to update the assignee field, as mentioned in the feature request JSWCLOUD-16862.

If you are able to achieve it with the option above, please let us know the steps you took so we can test it and properly add the workaround to the bug description.

[Josh Williams]

I must be losing my mind because I can't get it to work using the old workflow triggers. 

I had this working years ago on JIRA Server - most of our flow was fully automated.

Maybe it never worked for cloud.

[Petter Gonçalves]

Hey Josh,

I believe you're correct in saying that it never worked for Jira Cloud.

The big challenge here is that the integration with external systems (as Github) would be a breach to allow external users to impersonate Jira users because of the way that Atlassian Accounts works today.

That being said, our PMs are working on an alternative to achieve this goal, so keep posted on the related bug and feature request provided above. 

Thanks!

[Josh Williams]

I gotcha. 

I am using Bitbucket though - I linked the other issue but it is for a separate git provider (Github).

Hope this issue gets a bump