Creating new tickets on close or delete

maknet

Having an issue with new tickets getting created. Haven't been able to reproduce it (consistently), but here is what seems to be happening:

- when i try to DELETE or CLOSE multiple tickets (or sometimes just one ticket by itself), it seems to be coming back as a new ticket

theories:

- I think it happens a lot with "failure notices", so maybe there is an infinite loop going on? For example, our support e-mail sends an undeliverable e-mail, it comes back. Then maybe when i close it, do you know if the OST will loop-back and try to keep replying to itself?

setup:

- i was using auto-cron and this occurred. Last night i tried to switch to a manual cron system, but i don't think it is working (or fixing it).

Any help is greatly appreciated.

maknet

New information

when i go into the DB and delete the OST_ticket information for these recurring tickets, they still come back!

How does that make any sense? Or should i not be deleting them directly from the database?

Any help is appreciated. This isn't making much sense.

I have posted the e-mail below, i think it only occurs for the e-mail, so maybe there's some bad loop-back code or reference that's confusing it?

Lawrence

---

Hi. This is the qmail-send program at maknet2.inetu.net.

I'm afraid I wasn't able to deliver your message to the following addresses.

This is a permanent error; I've given up. Sorry it didn't work out.

63.247.137.86 does not like recipient.

Remote host said: 550 No Such User Here"

Giving up on 63.247.137.86.

--- Below this line is a copy of the message.

Return-Path:

Received: (qmail 84620 invoked by uid 89); 2 Sep 2010 20 -0000

Received: from unknown (HELO maknet2.inetu.net) (127.0.0.1)

by maknet2.inetu.net with SMTP; 2 Sep 2010 20 -0000

Received: (from secure@localhost)

by maknet2.inetu.net (8.13.6/8.13.6/Submit) id o82KVH61084618;

Thu, 2 Sep 2010 16 -0400 (EDT)

(envelope-from support@yyy.com)

X-Authentication-Warning: maknet2.inetu.net: secure set sender to support@yyy.com using -f

Date: Thu, 02 Sep 2010 16 -0400

From: " Support Team"

To: "pki08@xxx.com"

Reply-To: "Support Team"

X-Priority: 3

List: maknetlist

List-Archive:

List-ID:

List-Owner:

List-Subscribe:

List-Unsubscribe:

List-URL:

Message-ID:

X-Mailer: Pro Dada 3.0.0

Content-type: multipart/alternative; boundary="_----------=_1283459237814120"; charset="iso-8859-1"

Content-Transfer-Encoding: binary

MIME-Version: 1.0

Subject: Office closed Monday, September 6th for Labor Day Holiday

This is a multi-part message in MIME format.

--_----------=_1283459237814120

Content-Disposition: inline

Content-Transfer-Encoding: 8bit

Content-Type: text/plain

Content-length: 528

Dear Customers,

Our offices will be closed on Monday, September 6th, 2010 for Labor Day Holiday.

Thanks,

Click http://www.yyy.com/unsubscribe/index.php?email=pki08@xxx.com(http://www.yyy.com/unsubscribe/index.php?email=pki08@xxx.com) to unsubscribe.

--_----------=_1283459237814120

Content-Disposition: inline

Content-Transfer-Encoding: 8bit

Content-Type: text/html

Content-length: 854

maknet

Solution?

After some experimentation, i believe deleting the messages from the SERVER seemed to have helped.

Current theory is that my combination of IMAP or POP3 (leave on server) or whatever is messing up with OST.

The only confusing part is that it seems to only occur for the e-mails as noted above. For the "regular" e-mails, they close and delete fine. Maybe it's a mail header issue or something.

If anyone has any theories, that would be helpful.

hubze

Happening to me as well....

Having an issue with new tickets getting created. Haven't been able to reproduce it (consistently), but here is what seems to be happening:
- when i try to DELETE or CLOSE multiple tickets (or sometimes just one ticket by itself), it seems to be coming back as a new ticket
theories:
- I think it happens a lot with "failure notices", so maybe there is an infinite loop going on? For example, our support e-mail sends an undeliverable e-mail, it comes back. Then maybe when i close it, do you know if the OST will loop-back and try to keep replying to itself?
setup:
- i was using auto-cron and this occurred. Last night i tried to switch to a manual cron system, but i don't think it is working (or fixing it).
Any help is greatly appreciated.

This is happening to me as well, but my issue is with people having an "out of office" auto reply to emails. If I change the status, or close it, when I go back to the main dashboard, it has created a new ticket because of the same vacation reply coming in again from the email messaging going out letting them know their ticket was updated...

I do not want to have to shut those off, because I know people would like to be notified about an updated ticket, however with the large number of tickets we are working with, it is a real pain...any ideas on how to stop this? I wonder if this is the same issues you are having maknet?

ryanp

maknet:

How does that make any sense? Or should i not be deleting them directly from the database?

The biggest problem with deleting from the database is that any files attached to the ticket will remain on your server won't be deleted unless you do this manually.

Current theory is that my combination of IMAP or POP3 (leave on server) or whatever is messing up with OST.

This does make sense but how long does it take for the ticket to re-appear? If it is 5 minutes or so I would recommend archiving the message or using a rule to file it after the POP3 polling has been completed - this function is provider dependent.

Haven't been able to reproduce it (consistently)

Are you actively using the email account for tickets and other emails?

If you are then actions like filing some messages in a folder will likely stop the server providing the message to a POP3 fetch command again, this means that only messages remain in the 'inbox' on the server would have this effect.

hubze:

This sounds like a different issue and unfortunately it could be an issue you may have to live with. Sorry I can't help you much there mate.