How to automatically change the status of a task when a new task with a similar description arrives?

[eugeniy]

Please tell me how you can create automation according to this principle:
1. A task arrives with the subject "Error" Original problem ID:123.
2. Immediately or after some time, another task arrives with the subject "Error fixed" Original problem ID:123.
3. After the task with the subject "Error fixed" has arrived, you need to change the status of the task "Error" and "Error fixed" to Completed (or another status).
Can this be done?

[Aron Gombas _Midori_ · Accepted solution]

Wouldn't this be easier to model the whole "thing" with the same issue and two statuses?

• "Error" (created first)
• then transition to "Error fixed"

In my experience when you start to manage the same "thing" as two separate issues, it will just create further problems with syncing, linking, reporting, traceability, etc.

[edwin vasquez]

This seems like the best approach

[eugeniy]

I didn't quite understand how to do it. Could you explain a little more about how to implement this? The fact is that the first and second letters come automatically, but the second one may not come, and then the specialist needs to solve the problem himself and change the status of the task. And if a second letter arrives, for example, 5 minutes after the first one, then it is necessary that the first and second letters receive the status closed or some other status.

[Aron Gombas _Midori_]

I won't be able to give you a precise implementation plan, but I think you should represent the same "error" with a single issue, otherwise you will just create further problems for yourself.

I understand that there emails that need to transition the issue between various statuses. And sometimes email come, sometimes don't.

I'd roughly do something like this:

1. Jira side:
   1. Add a new issue type "Error"
   2. Add  a new custom field "Original problem" (maybe a number type field, if your identifiers are numbers) and add it to this issue type
   3. Add a workflow for this issue type with all the statuses that can be entered during its lifecycle 
2. Then implement an external mechanism:
   1. Regularly polls the maibox which receives the emails that determine the issue status
   2. Parses the ID from the email
   3. Connect to Jira REST API and run a JQL to learn if the corresponding Jira issue already exists, typically:
      "Original problem" = <the Id you parsed from the email
   4. If not found, it is a new problem -> create the issue through the REST API
   5. If found, transition it to the new status determined by the email

Makes sense?

[Rudy Holtkamp]

If the "ID:123" is always in the subject and always in the same format, you can grep it with an issue created automation rule and place it in a field e.g. "referenced id".

Then when you get a new issue, you first grep the id, and then check with lookupIssue if there is already an issue with that reference id. If so, you can copy the summary and place it as comment, and close the original issue and the new issue.

[Alex Koxaras _Relational_]

ΗΙ @eugeniy 

Is this about Jira?

Do all the email subjects has a specific format? (E.g. "error" will be on the next email "error fixed" and not "fixed error").

Your request could be feasible, but more info is needed. 

[eugeniy]

Theoretically, yes, everything will be according to the template.

[eugeniy]

For example, the first email has a subject: 

Problem: Unavailable by ICMP ping

Second: 

Resolved in 4m 0s: Unavailable by ICMP ping

[Logi Helgu]

Feels like this is all about using "emails" to resolve tickets...rather than working on them and updating them directly...or hooking repo commits...

Why not work on and update the tickets themselves...

...maybe I'm not understanding the context ;)

[eugeniy]

Tickets are forwarded automatically from the monitoring system

[Christof Hurst]

You can make a regex search in the subject for "ID:123" when importing the E-Mail or in an automation and then perform actions on the existing issue.

[Aradhana Gupta]

Hi  eugeniy,

Is there a reason why the one who fixes the ticket, cannot use JSM ?

Is the one who fixes the error a 3rd party (or customer in JSM terms)?

What you want can be achieved, but a lot of conditions ,preconditions need to be considered and may not always be foolproof. 

[eugeniy]

It happens automatically