/build/static/layout/Breadcrumb_cap_w.png

CustomerResponded ticket rule

I am not having much luck with Kace tech support on this so I guess I will ask here as I am being hounded by everyone on my team to get it working as they cannot tell when a customer has responded to their question/s.

I am having some issues with our CustomerResponded ticket rule. I have it setup to change from “Pending user information” and “Ticket Will Close in 3 Days Unless User Responds” to “User Responded”. For whatever reason, it is not working. When I change a status to one of the two above, it instantly changes the ticket to “User Responded” on ticket save. It should not change it until a user responds to the ticket. It used to work fine but all of a sudden, it started to mess up. I have reset it multiple times. I have tried it with other statuses. I even copied the rule from scratch from our test helpdesk to it and still will not work. I just reset our test help desk back to factory defaults and it still will not work correctly. I am not sure if the SQL is messed up somehow or if there is issues with the database. Below is the SQL code. Keep in mind that I have not modified the SQL myself. This is what the actual helpdesk has coded based on the built in rule. The and HD_STATUS.ID in (3,26) numbers are correct, however there are multiple number enties for new, opened, closed, and Need More Info. Therefore, those statuses are listed with six different ID numbers. Thanks in advance.



Select Query:
select distinct HD_TICKET.ID,
HD_TICKET.OWNER_ID as OWNER_ID,
HD_TICKET.ID as TICKNUM,
HD_TICKET.TITLE,
HD_STATUS.NAME AS STATUS_NAME,
HD_STATUS.STATE as STATE,
OWNER.USER_NAME as OWNER_NAME,
OWNER.FULL_NAME as OWNER_FULLNAME,
OWNER.EMAIL as OWNER_EMAIL,
UPDATER.USER_NAME as UPDATERNAME,
UPDATER.EMAIL as UPDATEREMAIL
from (HD_TICKET, HD_STATUS)
left join HD_TICKET_CHANGE on HD_TICKET_CHANGE.ID = <CHANGE_ID>
left join HD_TICKET_CHANGE_FIELD on HD_TICKET_CHANGE_FIELD.HD_TICKET_CHANGE_ID = HD_TICKET_CHANGE.ID
left join USER OWNER on OWNER.ID = HD_TICKET.OWNER_ID
left join USER UPDATER on UPDATER.ID = HD_TICKET_CHANGE.USER_ID
where HD_STATUS.ID = HD_TICKET.HD_STATUS_ID
and HD_TICKET_CHANGE.HD_TICKET_ID= HD_TICKET.ID
and HD_TICKET_CHANGE_FIELD.FIELD_CHANGED !='SATISFACTION_RATING'
and HD_TICKET_CHANGE_FIELD.FIELD_CHANGED !='SATISFACTION_COMMENT'
and HD_STATUS.ID in (3,26)
and (UPDATER.ID <> OWNER.ID or OWNER.ID is NULL)
and UPDATER.ID > 0



Update Query:
update HD_TICKET as T, HD_STATUS as STATUS
set T.HD_STATUS_ID = STATUS.ID,
T.RESOLUTION = CONCAT(T.RESOLUTION,'
Reopened'),
T.TIME_OPENED = IF(STATUS.STATE = 'opened', NOW(), T.TIME_OPENED),
T.TIME_CLOSED = IF(STATUS.STATE = 'closed', NOW(), T.TIME_CLOSED),
T.TIME_STALLED = IF(STATUS.STATE = 'stalled', NOW(), T.TIME_STALLED),
T.SATISFACTION_RATING = IF(STATUS.STATE = 'closed', NULL, T.SATISFACTION_RATING),
T.SATISFACTION_COMMENT = IF(STATUS.STATE = 'closed', NULL, T.SATISFACTION_COMMENT)
where STATUS.NAME = 'User Responded' and
T.HD_QUEUE_ID = STATUS.HD_QUEUE_ID and (T.ID in (<TICKET_IDS>))

0 Comments   [ + ] Show comments

Answers (6)

Posted by: airwolf 13 years ago
Red Belt
0
I'd suggest using the built-in CustomerResponded rule. The status will automatically be changed if anyone other than the owner responds to the ticket. So, if you are not the owner and you add a comment, it'll kick the ticket into the responded status.
Posted by: ustacp 13 years ago
Second Degree Blue Belt
0
ORIGINAL: airwolf

I'd suggest using the built-in CustomerResponded rule. The status will automatically be changed if anyone other than the owner responds to the ticket. So, if you are not the owner and you add a comment, it'll kick the ticket into the responded status.



That is actually the one I am using. It is changing the status when the ticket is saved after changing the status to “Pending user information” or “Ticket Will Close in 3 Days Unless User Responds” without ever adding a comment. The only thing that is added is the normal update showing that the status was changed by the owner. It does that on all tickets and I believe that is by default. I even tried it in a clean test helpdesk using the default statuses that are initially created with the helpdesk. I also tried creating a custom ticket rule using the same SQL code from the test helpdesk and it still would not work.
Posted by: airwolf 13 years ago
Red Belt
0
Are you set as the ticket Owner when you are changing the ticket status to "Pending User Information" or "Ticket Will Close in 3 Days Unless User Responds"?
Posted by: ustacp 13 years ago
Second Degree Blue Belt
0
ORIGINAL: airwolf

Are you set as the ticket Owner when you are changing the ticket status to "Pending User Information" or "Ticket Will Close in 3 Days Unless User Responds"?



OK, that is very strange. I just did as you suggested and it worked. It has always worked as the owner being set to the default "Unassigned". I thought I tried it that way but I forgot to change the submitter from me to another person. We have used this rule from day 1ish and have never had to set ourselves as the owner for it to work. I know it is not another rule causing it as I have disabled all of them and tried it as well. Do you know what would have caused this? Maybe it has been messed up since day 1ish and now it is actually working like it is supposed to? We are added to a helpdesk label, which is set in the help desk config as “Ticket Owners By Lable" = Helpdesk Staff. Therefore, that should automatically make us an owner even though the ticket does not say so, correct?
Posted by: airwolf 13 years ago
Red Belt
0
No, being a ticket owner in the queue just allows you to own tickets. For this ticket rule to work properly, the person setting the status must actually be set as the ticket owner in the individual ticket itself. Unassigned is still an "owner" with an ID of 0. If your owner ID in the database does not match the ID of the owner in the ticket, then the rule will fire. "Unassigned" as a ticket owner is just like "Bob Smith" as a ticket owner, as far as the rule is concerned.

You could duplicate the rule and make a modification to allow the "ticket owner" AND "anyone if the owner is unassigned" to modify the status without firing the rule.
Posted by: ustacp 13 years ago
Second Degree Blue Belt
0
ORIGINAL: airwolf

No, being a ticket owner in the queue just allows you to own tickets. For this ticket rule to work properly, the person setting the status must actually be set as the ticket owner in the individual ticket itself. Unassigned is still an "owner" with an ID of 0. If your owner ID in the database does not match the ID of the owner in the ticket, then the rule will fire. "Unassigned" as a ticket owner is just like "Bob Smith" as a ticket owner, as far as the rule is concerned.

You could duplicate the rule and make a modification to allow the "ticket owner" AND "anyone if the owner is unassigned" to modify the status without firing the rule.



I guess that makes sense. I just do not know why it worked up until this week. I know we have had multiple database crashes in the past due to our horrible SAN, which has been replaced. Maybe for whatever reason, it corrected itself over the weekend.

So would I change this section "and UPDATER.ID > 0" in the Select Query? If so, what is the correct syntax and where would I find our listed numbers? I know this (SELECT ID as ID, Name as NAME from HD_STATUS) creates a report for the status ID numbers, but I am having issues trying to get the right syntax for the owner to work.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ