How to set delay to create jira ticket after specific time using mail handler

[Prashant Mali]

I am creating JIRA ticket and HP ticket using same mail handler.HP ticketing tool is on cloud and our JIRA is on normal standalone server.so my main use case is that I want to link that hp ticket with JIRA once ticket created on both side.so that for doing this which is the best method to implement this case.

so tell me the easiest solution on the same issue.

[Nic Brough -Adaptavist- · Accepted solution]

You would need to write your own mail handler to do this.  However, I don't think it would work well, as the handler would have to stop processing until the "specific time", which means it would then clog up all the other email coming in.

Is there a reason behind this idea?  Could you just not send the email until it is needed?  Or have a status in the workflow that says "not yet" and and a field on the issue saying "this should become 'new' at this time", with an automation to read that and transition it at that time?

[Prashant Mali]

I am calling an event listener.and in that, there is my logic to check rest api response of other tool.and our JIRA creation time via email is less than that other tool.

[Prashant Mali]

tell me  the solution on this issue

[Nic Brough -Adaptavist-]

Sorry, that makes no sense in this context.  An email arrives and creates/updates an issue.

Your listener has nothing to do with that directly, so I don't know how it relates. 

"The JIRA creation time..." sentence, I can't even begin to guess what that means.

[Prashant Mali]

let me explain in detail,I am creating JIRA ticket and HP ticket using same mail handler.HP ticketing tool is on cloud and our JIRA is on normal standalone server.so my main use case is that I want to link that hp ticket with JIRA once ticket created on both side.so that for doing this which is the best method to implement this case.

previously, I used above logic to implement my use case.but problem is that hp take more time to create ticket using mail handler. so my create ticket event listener doesn't work for first time.It works for second time. 

so tell me the easiest solution on the same issue.

BR,

Prashant

[Nic Brough -Adaptavist-]

Putting arbitrary delays into it is the wrong approach.

What you really need to do is build a check that one system has the data you need.  I don't know what your HP system is, so I can't talk about it.  (HP sauce is nice, but I'm assuming you mean a Hewlett Packard system of some sort)

So, If I understand this correctly, what happens is

• an email is created and sent
• a copy of the email goes to the HP system to get it to create an issue
• a copy of the email goes to JIRA to get it to create an issue
• In JIRA, you have a field to refer to the duplicate in HP, let's call this "HP Reference" for now

The problem here is that these two processes are divergent and independent and timed differently, so what you're doing is trying to wait until HP have created the issue on their side, then query it for a reference.

What I would do in JIRA is forget doing it as part of the issue creation.  I would write a service instead.  The pseudocode for this might be along the lines of:

• Run every 5 minutes
• Run a query for "HP Reference" is empty and created > -10m
• For each issue found, query HP with whatever the criteria is for matching the issues up (summary?)
• If it returns a matching item, put the reference on the issue

This removes any need for arbitrary pauses or delays and provides you with a lot more resilience.

[Prashant Mali]

Oh Nic... Nice Job!!!

Finally,You understand whole problem

Thanks a lot.

Right now,I used Thread to implement my logic.and it works on UAT. Can you please share the drawbacks of this idea.that code will executed only for one project. so My question is, If I continue with this code for one project on Production. It is better or not?

BR,

Prashant

[Nic Brough -Adaptavist-]

Well, it did need you to explain what you were trying to do, so I could see what the real problem was, rather than just your "delay" solution.

I'm not sure what you mean by "thread" to implement the logic.  And do you mean for the solution I gave, or your delay one?  If it's the delay, then no, I still wouldn't do that on Production, it's not the right thing to do.