loginshare + normal esupport logins

[spidermonkey]

greetings...

we have an owned license for kayako, but we're having a problem creating a "mixed system" for handling our tickets. essentially what we want to have is the majority of our tickets handled via the normal, default method (user sends in email, mail gets popped and entered into kayako, ticket is created, email sent to user). we also want to have a couple closed ticket departments which are not open to the public, so to speak, via sending email, etc -- this is to be done via loginshare with our billing system logins (our billing system is a custom home-grown system).

we already have the first part working pretty nicely. we have most of our sales and informational emails all going through kayako, and it's working quite well.

we now want to have a support department which will be limited to known, paying customers which will be authenticated via our billing system logins with a loginshare. i created a new loginshare module and also a new template group which uses that loginshare module for authentication. i have the new support department tied to that template group and i've also created new "registered" and "guest" user groups specifically for this group of users (to keep the normal public users segregated from users created via the loginshare module). to a point, this also seems to work just fine. it correctly authenticates against our billing db and lets us only see the support department, etc.

however, we run into a problem when one of our loginshare users tries to login if, in the past, they had opened a ticket via email to one of the other public departments. in this case, their email address is already tied to a user record within the kayako system so when the login is being processed, kayako sees the match for email address and does not allow it to proceed.

for instance, if user1@host.com sends email to info@mybiz.com, kayako creates a user for this email address in the swusers table and stores the email address for that user in swuseremails table. also stored in the swusers table are the usergroupid and loginapi_moduleid values (if using default non-loginshare, the usergroup would be 2 and loginapi_moduleid is 1).

if that same user from above, who is indeed a paying customer and has a proper login with our billing system now tries to login (of course properly using the "...?group=groupname" on login page) they will not be allowed in and will instead get a bad login error message. i've stepped through the whole thing and found that the problem is when kayako checks to see if this user is already entered into the kayako system (i.e., has an account in swusers table).

in function insertUser() in functions_users.php one of the first things it does is run getUserEmail() -- all this function does is to see if ANY account on record is using this email address, regardless of which usergroupid they belong to, or which loginapi_moduleid the account was created for. if there are any matches at all, it returns false and the new user record is not created so the login via loginshare cannot proceed.

it appears as though all of the pieces are ALMOST there to do precisely what we want. we are able to create multiple template groups with different login methods, we are able to create multiple usergroups to keep users for each group separate, and the database keeps track of all of this nicely (each user record is stamped correctly with the group and loginapi id's). but for some reason, it appears as though parts of the system "ignore" those values meant to segregate and filter the groupings. it seems to me that if everything were working properly, there would be additional checks when checking for existing users, etc, to make sure the usergroupid and loginapi_moduleid were checked for the current group instead of just doing a global search as it appears to do now.

let me know if anything i've said above needs clarification.

please help!

[spidermonkey]

nobody?

does nobody out there have a similar setup with different login methods (i.e., one or more loginshares as well as the normal default system)? the system seems so ready to support this, even arranging users into the appropriate groups for each loginshare type, but apparently it doesn't allow users with duplicate email addresses even if those accounts are for wholly different login systems.