Servicedesk Tickets via Email - duplicate users created with ticket submission and SSO
I've got a new K1000 set up and I'm trying to integrate a web form for users to create tickets from (that's on our intranet site). Everything is working but one thing - and it seems to be a chicken or the egg scenario. Here's my setup and what's happening:
Users are authenticated via LDAP and SSO is enabled (not imported from LDAP).
Ticket Queue is set up to allow non-authenticated users to submit ticket (since the user doesn't exist in KBOX until they actually log into it - at which time their user is created.)
When the user enters a ticket into the form, the ticket is created and a user is created with their email address. When the user get's the opening ticket email and clicks on the link to see the status of their email, they are able to log in (via SSO) but have no access to that ticket. When you look at the user list, there are two users with the same email.. the one created when the ticket was opened (unathenticated) and one when the user clicked on the kbox link to view their ticket. (I assumed that the kbox would recognize that the email and not allow duplicates) I am aware of the @submitter email tokens and have experimented, unfortunately only useful if the user already exists.
I've also tried importing users via LDAP so that their user accounts are present before they eventually enter a ticket. This works too, in that the ticket is submitted and correctly assigned to the user account that was already present. Unfortunately, the user loses the ability to "single sign on" and has to sign in to the KBOX by re-authenticating. (of course this being new to them, they have no idea what the KBOX is or what credentials to use etc...)
Can anyone point out my folly? If I make the user account first - SSO doesn't work for the user, if I make the user account 2nd (via SSO) it's not the same account as the one that put in the ticket, so they can't access the ticket (and I have duplicate users with the same email address.)
There are no answers at this time