KACE Product Support

If I remember correctly, I think Kace actually uses something like that on their system. Not sure if it is via a rule or not. I think I remember replying to a ticket and it coming back as they were on vacation and it assigned it to another tech. Then again, it could be the other million tickets in companies I have open. :) I would also be interested in using a rule like this as well. Sounds like a great idea, especially when you use the help desk for other reason than just a help desk.

This can be done with a custom ticket rule. You don't need to specify dates. Just turn the rule off when the user is back from vacation. The problem, however, is that you'll have to manually assign tickets back to them from that point on, because you can't simply reverse the rule... otherwise Owner2's tickets are ALL going to get dumped back on Owner1.

I'll continue working on something to automate assigning Owner1's original tickets back to them, but for the time being this is the only thing I can think of. You could use a "previous owner" field to note the last owner of a ticket - this could be used to write a rule to reassign tickets previously owned by Owner1 back to him/her from Owner2. This would, of course, use up a custom field (of which you only have 15 per queue).

Select Query:
SELECT ID FROM HD_TICKET T
JOIN USER U ON (T.OWNER_ID = U.ID)
WHERE U.FULL_NAME = 'Owner's Fullname 1'

Update Query:
UPDATE HD_TICKET T
JOIN USER U ON (T.OWNER_ID = U.ID)
SET T.OWNER_ID = U.ID
WHERE T.ID in (<TICKET_IDS>) AND U.FULL_NAME = 'Owner's Fullname 2'

We do something like that here. In our custom field 4 we have people list the beginning date and the end date they will be out. (e.g. 2010-06-14 2010-06-15)

If a response from a customer comes in then a rule checks the date and takes action. In your case the action would be to modify the owner -- i'm guessing you already have something to change status.

The query for us looks like this (trimmed for brevity so i hpe the syntax is still good)

select HD_TICKET.ID
from HD_TICKET
JOIN HD_TICKET_CHANGE ON HD_TICKET_CHANGE.HD_TICKET_ID=HD_TICKET.ID
and HD_TICKET_CHANGE.ID=<CHANGE_ID>
left join USER U1 on U1.ID = HD_TICKET.OWNER_ID
left join USER U3 on U3.ID = HD_TICKET_CHANGE.USER_ID
WHERE
(
LEFT(TRIM(U1.CUSTOM_4),3)='out' or /* user field contains generic "out" */
(
NOW() > DATE(LEFT(TRIM(U1.CUSTOM_4),10)) and
NOW() < DATE_ADD(RIGHT(TRIM(U1.CUSTOM_4),10),INTERVAL 1 day)
)
)
and U3.ID <> U1.ID /* updater is not the owner */
and U3.ROLE_ID NOT IN (1,8) /* updater is not an admin */


A more complex solution to setup but more intuitive for techs to use could be to have a user asset thatis mapped to the user. The user asset would have a date-based field for start and end date. This way the fields would actually give a date picker which makes sure they enter a valid date value.

ORIGINAL: ustacp

If I remember correctly, I think Kace actually uses something like that on their system. Not sure if it is via a rule or not. I think I remember replying to a ticket and it coming back as they were on vacation and it assigned it to another tech. Then again, it could be the other million tickets in companies I have open. :) I would also be interested in using a rule like this as well. Sounds like a great idea, especially when you use the help desk for other reason than just a help desk.


Assigning new tickets over to a different tech would be an easy rule to setup. The problem with JesseLara's request is that he wants to move existing tickets over to someone else.

Keep in mind that KACE not only has custom rules in their production KBOX, they also have custom code in their KBOX written for their purposes that offer features that we may never have.

Gerald, that's a great way to do it! It takes up one of only 15 custom fields available to us, but it's a much simpler solution than what I was working on.

My suggestion only uses a custom field in the user record not in the ticket and even then you could move it into an asset. So all 15 ticket fields are still available. We don't have a rule to assign it back because we don't actually change the owner...we just nag a distribution group until someone picks it up. The problem for us is that auto-assigning it assumes that person is guaranteed to be available or even in the office...but what if they called in sick?

The default ticket list view is "mine and unassigned" so my recommendation is that if you are going to change the owner then change it to "unassigned" so that the people who take tickets will do something with it AND everyone will likely see it.

FTR, we have very little meaningful custom code on our kbox. Any code that we do have is for convenience and is usually obvious -- for example the display of user labels below the submitter's name -- and some of those changes make it into the product but we don't necessarily remove the custom code.

Thanks for clarifying. I was under the impression that DellKACE's KBOX was some secret science experiment cover-up sort of thing. If most of your tweaks are just custom fields and rules, then that gives me hope! Although, I'd really like to see an unlimited number of custom user/ticket fields with varchar lengths above 255 (like, oh let's say, MAX). It sure would help out in several dead-ends I've run into. And now I'm going off topic...

Seriously, you guys rule.

The default ticket list view is "mine and unassigned" so my recommendation is that if you are going to change the owner then change it to "unassigned" so that the people who take tickets will do something with it AND everyone will likely see it.

That’s how I was actually going to set it up. There are only three of us working the IT side of the help desk so it’s not too bad. Most of our tickets go to unassigned but a select few get assigned if it is something we are better at than anyone else. This will make it nice, since I have to monitor two other people’s tickets plus mine if they are off. Now it will get assigned to unassigned. Thanks for the information Gerald and Andy!