Group Templates - An update from our perspective

[Netintegrity]

First of the all, the Esupport product in general is good, I am quite impressed.

However the biggest disappointment is the Group Template handling. It was one of the prime reasons (not the only one) for purchasing the Kayako Esupport product.

I believe we have a good understanding of the Template side of the product, even though we have only been running it over a week.

To provide a summary, we have one domain name, but we have two distinct brand names, each requiring their own Front-end Page. We use the method of ?groupname=branda or ?groupname=brandb at the end of the URL, with each front end having its own logo.

The biggest faults that I can see are

1) The use of cookies to determine which template you used last, from our perspective this is flawed, as many are running Adware/Spybot/etc products which regularly clear out the cookies.

2) The registration success email that is sent out, contains only the default URL (e.g. no groupname). Since the successemail is a template that can be modified, we can make a boring "thank you client, you have been registered, please use this URL to access the helpdesk for future ticket requests". I say boring, as it appears that no variables such as $fullname, $login or $password are available to this template (RegisterSuccessMail). I could be wrong on this!!. Even if it was to remain "boring" we could get by with this, not ideal, but usable, except that the issues extend further.

3) When ticket responses are sent, again the default URL is sent as URL to click on. If they click on it, and the cookie has been cleaned in the meantime, they end up on the default site, causing confusion.

Whilst I do not have a complete understanding of the internals, nor do I want to get to much involved (even though I write a fair amount of PHP code - part of the reason why I purchased a product), I believe that it would not be a large matter to correct these issues.

From what I can workout, the system is taking the URL that is setup in the database, whereas if it temporarily took the argument (?groupname=BrandA) e.g. passing it to the registration email, passing it to the ticket response Email, this would be a reasonably simple matter.

The reason why this is important as an example.
We have a client who registers for the helpdesk, they get their successful registration email, and doesnt touch the help desk again for 3 months.

They finally get another issue, they look for the email that they filed away, and click on the URL, by now, the cookie is gone, they may have switched to using Firefox, or they reinstalled the operating system, or they are using another machine. They click on the URL, and find the wrong site (or at least the logo and knowledgebase). Now they cannot logon, and give up on using the site, which is exactly what we do not want them doing....

Anybody have some thoughts or tricks or tips that they may wish to share, or even confirming that it is exactly the same problem that they are grappling with.

Regards

Bob

using the latest stable 3.20???