(split) inability for a logged in user to change their email address

[sarahw]

Hi ,
Kayako is a great product, however many people have found that the inability for a logged in user to change their email address is a serious problem. The correct way around this at the moment is to add a new user email address via the staff operator interface. Of course this is very inconvenient for the user.

A simple, albeit dirty (!) way to get around this issue is to attach a trigger to the ticket table that inserts the new email address automatically. Of course you need to change the submit ticket template for registered users so that you can enter an arbitrary email address.

The required SQL is below:-

create trigger add_email_address AFTER INSERT on swtickets FOR EACH ROW insert ignore into swuseremails values(null,NEW.userid,NEW.email,0);

I hope this is useful for anone else trying to integrate Kayako seamlessly with there applications.

[Jamie Edwards]

Hi Sarah,

Thank you for sharing this. I have split your post from the other thread as the two didn't quite go.

This is something we are looking to fix, but nonetheless thanks for the quick work-around.

[Matthew]

Sarah, can you describe in a little more detail how this would work? I think our company could use a feature like this.

[sarahw]

Hi Mathew, sure. Let me descibe the context for our particular solution.

We have a web application that registered users log into, and we want user support to be specific to each registration. In particular we want login to Kayako to be completely seamless. So, when the user is logged into our application they only need to hit the 'support' button, and a pop window appears, in which they are already logged into Kayako, under their Company wide subscription. Although we are new to Kayako, looking through the forum suggests many people have a similar scenario.

To integrate Kayako so that it will behave in this way, I did the following :-

1. In Kayako Admin create a a new Template Group called, for example. MyAppRegistrations
2. Modify the submit ticket template for this group so that Email, and Full Name fields are shown (by default they are not for registered users). I have attached an example template, that has only minor modifications to the original.
3. Rather than write our own LoginShare module, I simply used the existing vipercart variant supplied, and created a dedicated kayako_users table on our DB. This has the advantage that you do not need to but the Kayako source license (sorry Jamie!).
4. Now when someone registers with our application, we also make an entry into the kayako_users table, so that registration can be seamless.
5. OK, we do not want the user to have to physically login to Kayako, since they are already logged into our application. To achieve this I simply created a popup window that contains a hidden form, which is automatically submitted when loaded (the login info being passed to the form via the original URL). To make this form simply take the associated login form from the Kayako page, and set the enclosing tables style to 'style=display:none'. I have attached an example with hard wired username and password.
6. Now at this stage all seems rosey, seamless login is achieved; however, and this is the real problem, if you use an arbitrary email address for your submitted ticket (rather than the one that was originally used in the Kayako registration) you cannot view your own tickets, since Kayako uses the email address as the effective primary key for the Company registration.
7. This problem can be resolved at the operator end by manually adding a new email address to the associated user (there is a link under the user form to add more email addresses); but of course this is not satisfactory, since every time a user wanted to use a different email address they would need to send a support ticket to get the new address added!
8. Now referring to the original post, the way round this is to attach the trigger to the Kayako ticket table (swtickets), so that any new ticket INSERT results in the additional email address being added to the associated users email list automatically. Note that the insert ignores duplicates. In short, the trigger is simply doing what the manual operator would have to do. For completeness here is the trigger again,

create trigger add_email_address AFTER INSERT on swtickets FOR EACH ROW insert ignore into swuseremails values(null,NEW.userid,NEW.email,0);

Having done this last stage, the solution now works fine; although I am the first to admit its not ideal - I await the forthcoming API for this.

Hope this helps :-)