nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Need to delete trigger issue in/after branch

Blerim

Hi,

i have a rule that uses a JQL to find issues, then make changes to these found issues

this needs to be done in a branch obviously

but now i need to delete the trigger issue created, but only if the JQL where able to find any issue

i tried with a global variable but it seems due to async run ob branches the delete issue action outside of the branch is not succeeding

and i cannot use delete issue inside branch because this would delete the branch issue found itself right?

how to solve this, any ideas?

Accepted answers

Ste Wright

Hi @Blerim

Just to confirm...

Rule is Triggered against an Issue (somehow)
There's JQL which then runs
If the JQL finds Issues, delete the Trigger Issue
If the JQL find no Issues, don't do that

...is this correct? If yes, see below.

---

You should be able to do this with Lookup Issues - for example...

Trigger: Issue Created
Action: Lookup Issues
- JQL = <JQL Here>
Action: Re-fetch issue data
Condition: If/Else Block
- IF...
  - Sub-Condition: Advanced Compare Condition
    - First Value = {{lookupIssues.size}}
    - Condition = does not equal
    - Second Value = 0
  - Branch: Related Issues
    - Type = JQL
      - JQL = <Repeat JQL Here>
        Branch-Action: Action Here
  - Action: Delete Issue
- ELSE-IF...
  - Sub-Condition: Advanced Compare Condition
    - First Value = {{lookupIssues.size}}
    - Condition = equals
    - Second Value = 0
  - Sub-Action: If required

---

A few notes on this rule...

The Lookup Issues Action is required first - this is why the Re-fetch issue data Action is required, to slow the rule down and try to ensure Lookup Issues happens first
Note that the Branch and the Delete Issue Action are at the same level, Delete Issue is not in the Branch
If no additional Action happens when the JQL returns zero results, you don't need the ELSE-IF - you can just leave it blank as Add else. The additional Condition is only needed if there's an Action to take here.

---

Let us know what you think!

There's some assumptions I've made here though as we don't know what the full rule looks like.

If this isn't quite what you need, could you provide that information? I.E what the Trigger is, and what other Conditions/Actions/Branches are in the rule? A screenshot here might be very beneficial

Ste

All comments

Ste Wright

Hi @Blerim

Just to confirm...

Rule is Triggered against an Issue (somehow)
There's JQL which then runs
If the JQL finds Issues, delete the Trigger Issue
If the JQL find no Issues, don't do that

...is this correct? If yes, see below.

---

You should be able to do this with Lookup Issues - for example...

Trigger: Issue Created
Action: Lookup Issues
- JQL = <JQL Here>
Action: Re-fetch issue data
Condition: If/Else Block
- IF...
  - Sub-Condition: Advanced Compare Condition
    - First Value = {{lookupIssues.size}}
    - Condition = does not equal
    - Second Value = 0
  - Branch: Related Issues
    - Type = JQL
      - JQL = <Repeat JQL Here>
        Branch-Action: Action Here
  - Action: Delete Issue
- ELSE-IF...
  - Sub-Condition: Advanced Compare Condition
    - First Value = {{lookupIssues.size}}
    - Condition = equals
    - Second Value = 0
  - Sub-Action: If required

---

A few notes on this rule...

The Lookup Issues Action is required first - this is why the Re-fetch issue data Action is required, to slow the rule down and try to ensure Lookup Issues happens first
Note that the Branch and the Delete Issue Action are at the same level, Delete Issue is not in the Branch
If no additional Action happens when the JQL returns zero results, you don't need the ELSE-IF - you can just leave it blank as Add else. The additional Condition is only needed if there's an Action to take here.

---

Let us know what you think!

There's some assumptions I've made here though as we don't know what the full rule looks like.

If this isn't quite what you need, could you provide that information? I.E what the Trigger is, and what other Conditions/Actions/Branches are in the rule? A screenshot here might be very beneficial

Ste

Blerim

Hi @Ste Wright ,

thank you for your suggestions and time

i read you example and i think it has the same flaw as my rule.

sadly i need advice how to run an action for the trigger issue in or after the branch because i really need it *after* the branch.

since jira executes branch actions async your example has the same flaw as my rule

let me explain, the jira mail handler is rather simple and in our situation we do have a lot of external email communication. those mails do not have the mail-id in the header when it reaches jira to let it automatically append to the corresponding issue.

the only other option apart from the mail-id in the header is relying on the mail subject, but since the external systems/customers do not know beforhand the jira issue-id or sometimes ignore this information we need to link our jira issues with a known value of the external ticket-id that is present in the mail subject of the external ticket system.

long story short, the whole consume part based on the mail subject works as expected in my rule, but it still leaves me with a new issue created in the queue that i dont need anymore after it has been consumed to the existing issue...

let me describe what my rule does

When: Issue created

Request Type equals Emailed request

For JQL cf[xxx] in ({{summary.split(" ")}}) //simplified

Then: Edit issue fields Attachment Copy Attachment from Trigger issue

And. Add comment to issue {{triggerissue.reporter.displayName}}

and now i dont know how to tell jira to delete the trigger issue, after it has done all the copy attachment and comment

Ste Wright

Hi @Blerim

The difference is my rule uses a Lookup Issues Action prior to the IF/ELSE / Branch - so it already found the related Issues before it starts actioning the wider rule.

I tested this rule before I posted it, and it works fine for me. Could you try testing it using your rule parameters?

Ste

Blerim

Hi @Ste Wright thank you for your help and time, i did set this rule up and it seems it is working. attachments and comments are written to the trigger issue, and the original new issue is also deleted now. I tested this with a simple mail and with a mail with 5mb attachments. 👍

would you kindly explain why the information from the trigger rule are able to write to the branch rule even when delete issue action is executed before? Is jira here doing something like undocumented caching when doing *lookup issues* and *re-fetch issue data* before executing the branch?

because in the test with the 5mb attachment i see in the logs that it deleted the issue before writing the comment. the comment is copying data from the triggerissue and still it worked despite the issue has been deleted?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software-cloud

jira-service-management