We run Kayako fusion over at BlueThunder, and one of the issues I have had is dealing with sub-departments.

e.g.

GROUP1

• dept1
• dept2

I do not want customers to be able to to submit tickets to the parent department "GROUP1",  as this is just a a group/label, but fusion provides no way to stop this as it treats everything as a department., and does not allow to simply treat the parent as a group.

I never found any solution to this, so decided to do it myself, hopefully others may find this useful.

In the template editor, find the template named "submitticket_departments"

Find the following line, right after the first <(foreach block

<td width="16" align="left" valign="middle" class="zebraodd"><input type="radio" name="departmentid" onclick="javascript: ToggleTicketSubDepartments('<{$_item[departmentid]}>');" value="<{$_item[departmentid]}>" id="department_<{$_item[departmentid]}>"<{if $_selectedDepartmentID == $_item[departmentid]}> checked<{/if}> /></td>

and replace it with this

<td width="16" align="left" valign="middle" class="zebraodd"><input type="radio" name="departmentid" onclick="javascript: ToggleTicketSubDepartments('<{$_item[departmentid]}>');<{if count($_item[subdepartments]) >= 1}>unselect(this);<{/if}>" value="<{$_item[departmentid]}>" id="department_<{$_item[departmentid]}>"<{if $_selectedDepartmentID == $_item[departmentid] && count($_item[subdepartments]) == 0 }> checked<{/if}> /></td>

This will stop any departments that have sub-departments being selected, even if it is set as the default department.
If you also want all the departments to be expanded by default

find this line, after the second <(foreach block

<tr class="ticketsubdepartments_<{$_item[departmentid]}>" style="<{if $_displayParentDepartmentID != $_item[departmentid]}>display: none;<{/if}>"> 

and change it to

<tr class="ticketsubdepartments_>{$_item[departmentid]}>">

You may have noticed that if your search your knowledgebase certain articles do not show up, such as if you search for “FTP” or “VPN”, you get nothing.

This is because MySQL by default does not index words with less than 4 characters, which is for performance issues.

To get around this you need to edit your my.ini file or whatever file contains your MYSQLD settings.

Find the following setting: ft_min_word_len
and change it’s value to 3.

If your using MySQL Workbench, then see this screenshot.

You then need to rebuild your KB index, login to your FUSION admin, go to Knowledgebase –> Maintenance and click rebuild.

You should now be able to search and find articles using 3 letter words.

If it still doesn’t work, then you may need to REPAIR the tables “swkbarticles” and “swkbarticledata” which will re-index then using the new value.

In PHPMyAdmin, go tot he table view, check the 2 mentioned tables, scroll down to the bottom and choose “repair” from the dropdown list.

We recently(ish) updated our helpdesk from Kayko v3 (SupportSuite) to V4 (fusion), yes they also renamed it as well just to be awkward, shouldn't have then started with FUSION version 1.0 in that case ?
While FUSION has a lot of features, a lot of them have bugs and don;t work well with each other and considering how many issues I have found, I have to assume most customers only use Kayako’s product in a very simple way and do not make use of all the features to the extent that I do.

Anyway as the months have gone by I have found various issues, differences, bugs and gotchas, which I thought I would start recording on my blog for anyone else that upgrades and finds themselves with these issues, not to mention for my own reference.

I strongly suggest that you check your PARSER LOG on a daily basis for emails which have been blocked/rejected until you have your system finely tuned and working perfectly.

As usual the Kayako support has been a frustrating struggle to work with as I predictably always have to explain to them how their own product works, how email works, why their answer is wrong and why my issue really is an issue and often end up find the workaround myself anyway.
The number of times I have to explain to them that any email with the word “automated” in it, does not mean it is an auto reply sent by an auto responder, SIGH!

Anyway here is the list so far.

1. Force Queue on Incoming Emails
   Email queues have this new setting which is enabled by default. If Enabled, the system will force all emails in the mailbox to use the same queue from which the mail is being downloaded. If you use email aliases for different depts, this will screw that up and emails will all end up in 1 dept.
2. No more Private/Public alerts
   In V3 every user could setup their own alerts and choose what their received emails about, and no-one else could edit these.
   This has gone now, and there are only global notifications that everyone can view and edit. This makes setting up alerts only for a specific person more of a PITA.
3. Delivered to headers are not parsed
   If you have emails (such as monitoring or alerts) which get sent to a customer and also bcc’d into your ticketing system, and you create a parser rule to allow these emails in and bypass your other rules, it may not work. Currently you need to modify the parser code to make it process delivered-to header.
   To allow parser rules to work on "delivered to" header.

Edit the class.SWIFT-Mime.php and find this line around 258
foreach (array('to', 'cc', 'x-rcpt-to','bcc') as $header)
change to
foreach (array('to', 'cc', 'x-rcpt-to', 'delivered-to','bcc') as $header)

4. Catch-all rules do not work as expected
   If you have a catch-all rules to simply accept all emails from a certain address, e.g.
   /^alerts\@.*$/i
   Then this will not work, and the email will still be rejected by other criteria.
   This reported as a bug.
5. Parser rules not executed in correct order
   If you need them to run in a specific order then you may find emails being rejected. This is reported as a bug and there is a FIX available on their site.

more to come..

One the many problems I have found with Kayako SupportSuite is that it only checks the TO and CC addresses, this applies to email queues, parser rules and catch-all rules.
This means that if you have emails that are BCC'd into your ticket system, they wont work. Situations where this may be required is where you have an automated system that sends out overdue invoice alerts/reminders to customers and BCC's them to you so that you can action them.

The way round this is to tell the parser to check additional email headers, which headers you need will depend on your mail server. Google Apps for example uses a "delivered-to" header to record the final destination of the email.
To find out which header the destination email address is stored in, simply check your parser log and check the headers for a rejected email.

To add additional headers edit the file "<installation folder>\includes\functions_mime.php

Around line 130 find the following line

foreach (array('to', 'cc', 'x-rcpt-to') as $header)

and change it to

foreach (array('to', 'cc', 'x-rcpt-to', 'bcc','delivered-to') as $header)

Obviously you can add any number of additional headers in the same way.
I have also discovered that the CATCH-ALL rules do not work on the FROM address, presumably because the catch-all parser also uses the above code.
You may also be interested to know that the parser rules are post processors and will only parse emails that have already been accepted into a queue, so a queue must exist for the destination address.
The catch-all rules are pre-processors and will parse emails BEFORE processing them into a queue, so you can use these to process emails that would not otherwise be accepted as tickets.
Unfortunately resolving this issue was another painful battle with Kayako support, requiring screen shots, multiple repeat explanations and explaining how their own software works yet again.
As has been the case many times, their original work around/suggestion was to create a catch all rule with the following regex "(.)*", which will basically bypass all rules and queues and accept any email into the system, including every bit of spam.
I really wish their support staff would use a bit of common sense.

I have recently been having a right nightmare with Kayako SupportSuite as tickets have been coming in to email addresses that we do not use or do not exist and have thus been getting rejected and we never see them.

It turns out this is actually an old *issue* that I discovered long ago but had since forgotten about.

As you will know if you use Kayako SupportSuite/eSupport ( or Fusion as it is now called ) you create email queues, a queue must exist in order to process incoming email sent to that address, and you can also specify the FROM address that the queue uses when sending replies.

So you may wish to accept incoming email to:-

[email protected]

[email protected]

[email protected]

In which case you need a queue for each address for each dept, and you would of course expect that when email is sent OUT from the system, it will use the same queue and will either send from the original queue address or the alternate "From Email" address if you have specified one.

This unfortunately IS NOT what happens. It turns out that the queue that an email came in on bears no relevance to the queue used outgoing mail. When SupportSuite sends an email out, it simply uses the last queue in the list assigned to the tickets current dept, I.E. the most recently created queue, and then sends emails from that address.

This is a major issue for many reasons.

1. You may not want ALL QUEUES to be used for outgoing mail, some of them may just be for processing incoming mail only.
2. That queue may have the wrong email address for the dept. the ticket resides in
3. That queue may be using an email address that you do not want to be made public or used by customers, such as it might be used to bring automated emails in to the ticket system
4. You may be using that queue for testing and the email address will never be used outside of that, so you of course do not want tickets being assigned to that address or customers replying to it.
5. You may lose email as a result.

Not to mention the fact that this also rather defeats the whole point in having email queues for me, you would be better off just creating rules to parse the emails, but alas this does not work.

We have had all of these scenarios without realising, and I suspect many other users of this product have also had the same issue, believing as you would that the correct queue is being used for outgoing emails.

the problem is that there is no easy way to work around this problem, all you can do is make sure that the last queue in the list is a valid email address that you do not mind sending email from, there is no way to force the correct queue for the correct dept.

Even if you do this, you may still have a bunch of tickets out there that were sent from the wrong address. So if you were in scenario 3 above and doing some testing with a new queue which you have since deleted, then your customers will be replying to a non existent email address/queue and their emails will thus get rejected by the parser and you will never see them.

The only solution to this, is to a) delete the queue, or b)create a catch-all rule to redirect the emails to another queue or dept.