mapping lum_user to multiple tables

widox

Has anyone tried mapping the users table to multiple tables from another app? I have an existing app that has a main user table and an associated profile table. I'd like to add the extra Vanilla fields to the profile table and not the main user table. But the trick is, *some* of the fields like password and user_id are in the main table. So Vanilla would have to search both of those tables to extract data. But I only see a way to re-map the user data to a single table. Has anyone done this or have a good idea on how this could be accomplished? Thanks!

widox

no ideas on this one? would I have to pretty much re-write stuff to make this work?

Dinoboff

You have to create you own Authenticator, check out other integration examples: http://lussumo.com/docs/doku.php#external_application_integrations

widox

I've seen those examples. But essentially what I want to do is use 2 tables for the Users table, not just 1 like the examples do. I'm guessing that's not possible considering that all the other parts of the system only look for 1 User table. But if anyone has any ideas I'm all for it. I'm just getting into Vanilla.

Dinoboff

Forgot my last comment. I don't think your problem is the authentication; I guess you would like to populate a user object with data from different tables.

You can't map the user table to multiple tables but you can extends the UserManager class so that the User object is populated with data from different table. But this new UserManager won't be used for creating $Context->Session->User because it is created before the extensions are loaded. I might be able to fix that in Vanilla 1.1.5.

widox

Well, I'd probably have to extend both classes. It would need to be authenticating a Vanilla user against my other system's login. I'll take a look at the UserManager class and see what it's about. What's the timeline for a 1.1.5 release, and what would be the change from 1.1.4 to help accomplish this?

Dinoboff

1.1.5 should have been release on monday but it will probably be release next week instead.

I am away today and tomorrow, so I can patch Vanilla right now but it will be like replacing the default authenticator. Vanilla won't include People.Class.UserManager.php but the file defined in $Configuration['USER_MANAGER_MODULE']. I still have to see how the BuilderFactory will also know which UserManager class to use.

widox

Interested to see if this will work. I took a quick look at the UserManager class, are you suggesting that I would have to refactor most of those methods to pull from the separate tables? Is it correct to assume the rest of the system would still function the same without problems? Thanks for your help and hope to see 1.1.5 next week!

Dinoboff

You are correct. Your version of UserManager just need have the same protocol. Using some setting, Vanilla will load and use your version of UserManager.

You just need to create on extensions (e.g.: MyExtension) and create the files for you version of UserManager (e.g.: MyUserManager) and maybe User (e.g.:MyUser):
/Path/To/extensions/MyExtension/People/People.Class.MyUserManager.php
/Path/To/extensions/MyExtension/People/People.Class.MyUser.php

then in /Path/To/extensions/MyExtension/default.php:
[...] if (!isset($Configuration['MY_EXTENSION_VERSION'])) { // Adds persistence Object Factory reference AddConfigurationSetting($Context, 'OBJECT_FACTORY_REFERENCE_USER_MANAGER', 'MyUserManager'); AddConfigurationSetting($Context, 'OBJECT_FACTORY_REFERENCE_USER', 'MyUser'); // Tells vanilla where to find your class AddConfigurationSetting($Context, 'LIBRARY_INCLUDE_PATH', $Configuration['LIBRARY_INCLUDE_PATH'] . ';%EXTENSIONS%/MyExtension/'); AddConfigurationSetting($Context, 'MY_EXTENSION_VERSION', '0.1'); }

widox

Big thanks. I'll be working on that next and sure to have more questions!