KACE Product Support

In further research, I have discovered that my 'Re-Opened' status is considered a default status. This is probably why tickets are coming in and showing as Re-Opened...although my status of 'New' is also a default status, so I don't know how or why the system is choosing the Re-Opened over the 'New'...especially when the ticket default says it should be assigned to 'New'.

Is there a way to make 'Re-Opened' not a default value? If not, the only resolution I see to this, is to delete the Re-opened Status and then when a email comes in to a closed ticket, it will make the ticket 'assigned' or opened instead of 're-opened'.

I haven't figured anything out on my 2nd request where the email goes out with the link to Kbox in it. I only see one kind of email response that goes to everyone whether internal or external.

You might need to check your custom rules out as far as the re-opened thing goes. We've run into it a few times here during testing (we're now in production). Below are some things we found which created issues and the same thing you've got happening.

1) We were closing jobs with no owner assigned. They would immediately re-open because there must be an owner at close.
2) Custom helpdesk ticket which changed the status of the job to 'Technicians Notified' was setting the status to 'stalled' and then posing a change to the ticket, our custom 'Re-Opened' rule was seeing this and setting status to 'Re-Opened'

I would check your rules and go from there. Also, as you say, ensure that your queue configuration is set to use the correct default value, ours is New.

Where did you find that your 'Re-Opened' status is considered a default status? Where does it show this?

As far as unauthenticated access to view tickets goes, I dont believe this is possible. Best you could do is create a generic account for people to use. Maybe create a custom ticket rule to create a user for each email address that it receives an email from and on their first email to the helpdesk it sends their login details to them and the link to the ticket.

Unauthenticated access is not something I would have guessed this was built for.

Let me know how you go and I'll see if there's any more info I can offer.

Cheers

Thank you Rooner for your response. I will recheck the rules, however, I had not set up any rules to my knowledge in regards to this. We are new on kbox and this part is not in production yet---I'm still testing and making setting changes. As for the default re-opened status, when I go into our Tech Support tab (it was originally named something else and I changed it to Tech Support) then go to the Queues and choose my Tech Support queue, then configuration..and expand the 'customize fields and layout'....down in the status values section, Reopened, the state is opened then in the far right column, there is the edit button and a move up button. I read somewhere that those without the trashcan are default values and cannot be deleted. I believe it was there when we got the box. I have 4 that have no trash can.....New, Assigned, reopened and closed. My settings in the tech support configuration page under Indcident defaults indicates that the status should be 'new'...but when i would look at newly created tickets--ones that the email came in on that no one has looked at yet, they were indicated as reopened.
As for multiple users (my tech team) seeing all tickets or getting an email.....having them log into the admin console will grant them that ability......I thought i had read that tickets should be worked from the user log in, but KACE support said no, that through my user rules I set up, they can log into the admin console and see all the tickets without having ability to change things I don't want them to change. Also, they told me if my techs sign into the admin as kbox/adminui, then it auto refreshes and they do not need the email. I have created a generic user that they all could log in with, but it still doesn't send an email to them when the ticket comes in.

Texas,
The default you're mentioning here about the statuses is not really the right way to describe it. More so those 4 statuses are just required by the Kbox so it doesnt let you delete them. They arent really the 'set default'. The default for new items is the one which you select under Queue\QueueName\QueueNameConfiguration\Ticket Defaults, or Incidents as you've changed them too. If this is set to New then there is something else which is changing the status of the ticket and it should read as such when you look at an Incidents history.

Please try disabling any custom ticket rules that you have, and also any System Ticket (Incident) Rules which might be enabled and see how it goes.

Re the user/email issue:
Do you have an email account which they all share? Have you set that email address correctly in the Kbox user? Have you checked the appropriate boxes at the Email on Events section?

We had limited succcess with this so we went a different way for notification, we set up a rule which detects the status of 'New' and then emails a set list of technicians (Service desk managers who's email addresses are typed into the query) and then changes the ticket status to 'Technicians Notified' to re-assure that staff on the team have received the ticket and were looking into the matter.

Let me know if you think this sql query might help you, ie, it could send emails to the technicians real email addresses to notify of new tickets while using their generic login still.

Keep us in the loop for your progress mate.

Roonerspism,

Thank you so much for your help and my apologies for taking so long to respond---this project kind of got put on the back burner for a couple of months, due to a larger project our developers needed our help on.
Ok, the tickets are coming in as 'new' now...
The email issue---the team is getting the emails for new tickets now---but they are also getting emails for tickets that they should not be getting emails on. Once a ticket is assigned, then, to me, only the person that is assigned the ticket, the customer, and anyone in the cc list should get further emails, but my whole team is getting ticket update notices, etc. So i still need to review the email on event list and see what needs changing. However, your information/query for new tickets sounds helpful. I would be interested in testing that to see if it would work better for me. I am trying to get the emails to the techs to be only what they need to work their tickets....they seem to have a case of mailbox overload [:-]
Brandy

faq 613 is what I recommend following. If all your tickets come in with a default category and that category will be changed right away then go with the simple method. If not then you can use the rule from it to fire only when the ticket is created.

For notifications beyond ticket creation it sounds like you can use the checkboxes for email on events.

Awesome! This looks like it will be my answer!

~Brandy