2 client replies cause tickets to get set to non-existent status

[barry]

Currently we have Kayako configured to automatically change the ticket status upon client reply. This part works, but if a client replies twice without a staff reply in between, the ticketstatusid gets set to 1. The problem is that ticketstatusid=1 does not exist in the swticketstatus table. This effectively causes the ticket to get set to an empty status which makes it very difficult to locate in the interface. The ticketstatusid it should be set to is 13. A work around is to run a query that finds all the tickets with ticketstatusid=1 and changes them to 13, but this doesn't update the ticket counts in the interface. Any help that could be provided would be much appreciated.

[eiden]

Check that "Default Ticket Status for Client Reply" (AdminCP -> Settings) is set to the correct status.

Do you have any mail parser rules that changes the ticket status?

[barry]

Yep, the default status is set correctly and it sets it to this status if the client reply is after a staff reply. It's only when there are 2 client replies to the same ticket with no staff reply in between that this happens.

No mail parser rules.

[Mahesh Slaria]

Hi barry,

Surely there is some misconfiguration, Please provide me Admin access on me email to look into this issue.

Thanks.

Regards,

[barry]

Mahesh,

Email sent.

Thanks,

Barry

[kenh]

I have this same problem...

If the client replies twice (without a staff reply in between) then the Ticket Status become blank..

After hacking around in the database - actually the status ID in the swtickets table for this ticket is set to a value 1 (which is a non existant Status ID - I removed the default ones and added my own so my Status ID's start at 4)

This is a serious problem and needs fixing quickly.

.. KJ

[leyton01]

**use the following suggestion with care**

1. Create a new status - call it something similar to what you want as your default. -do not change any ticket status yet-
2. Change the [ticketstatusid] of the *new* category in the [swticketstatus] table in the SQL database to 1.
3. You now have a default status - you can move all the old status tickets to the new status and do whatever renaming you need.

No responsibility for any breakage this might cause. Take a backup first!! Don't just renumber the old status in the table - it will make all the old status tickets disappear as there is no matching number.

[kenh]

Originally Posted by leyton01

**use the following suggestion with care**

1. Create a new status - call it something similar to what you want as your default. -do not change any ticket status yet-
2. Change the [ticketstatusid] of the *new* category in the [swticketstatus] table in the SQL database to 1.
3. You now have a default status - you can move all the old status tickets to the new status and do whatever renaming you need.

No responsibility for any breakage this might cause. Take a backup first!! Don't just renumber the old status in the table - it will make all the old status tickets disappear as there is no matching number.

leyton01,

That is what I did (as a temporary workaround) - I named the new status 'Lost'

Had a browse around the code and couldn't really see why it was defaulting to 1 - in the mail parser it determines if the mail is a reply (which is working as the reply is added to the ticket), then adds the post as a client relpy and then if there is a default customer reply status set it should update the ticket to that status ID...

Anyway, Kayako need to fix it - hopefully sooner rather than later...


.. KJ

[Mahesh Slaria]

Hi,

This issue is fixed and I will push this fix in upcoming CVS build later today. You can email me at mahesh.slaria AT kayako.com to get patch for this issue.

Thanks.

Regards,

[barry]

Mahesh,

Thanks for the patch. Looks to be working great!

[speeduneed]

I created a paypal script to accept payments for tickets.
When the client is returned to my website from paypal I run....

$query = "UPDATE swtickets SET ticketstatusid = '5'
where ticketid = '".$_REQUEST['item_number']."'";

This works fine. But when I check the admin area the ticket counts are wrong in the tree menu. What query do i need to run to make sure the a ticket id status is updated properly. Do I need to add 1 and remove 1 from a status somewhere. I hunted through the database and I could not find where the $_assigns were getting there numbers from.

Thanks for the help....

By the way I have paypal integration now!!
Next Auth.net

Speed