Customization of User data

I have requirements to remove some user fields and add some additional ones not in the core WebUser system. Does anyone have examples of how to best approach this using MODx? Any suggestions or information is appreciated.

I also have a client that would like to have the username be the email address. This seems like it might be a significant change. Any other thoughts in this regard?

Hi,

When linking the MODx user system with an external app or module you should create and store additional user data inside a separate table. Example,

Table: MyAppUserData
Fields: uid, skill, workaddress, message, etc

Now the uid inside MyAppUserData will use modx uid field to link web users to the MyAppUserData data table. That’s one way of extending the web system on a per app basis. The reason why I would recommend doing this as oppose to modifying the core user fields is because requirements will vary from app to app. Does makes much sense to cluter the web user info screen with fields 10 seperate apps does it? You should let each app handle it’s own extended data sets.

As for using emails as user name you can create a web signup template that ask for the user’s email address instead of a user name and use the email address as the user name. See the WebSignup snippet on how to create a web signup form.

Quote from: xwisdom at May 31, 2005, 06:23 PM

Hi,

When linking the MODx user system with an external app or module you should create and store additional user data inside a separate table. Example,

Table: MyAppUserData
Fields: uid, skill, workaddress, message, etc

Now the uid inside MyAppUserData will use modx uid field to link web users to the MyAppUserData data table. That’s one way of extending the web system on a per app basis. The reason why I would recommend doing this as oppose to modifying the core user fields is because requirements will vary from app to app. Does makes much sense to cluter the web user info screen with fields 10 seperate apps does it? You should let each app handle it’s own extended data sets.

This isn’t really a separate app, just the default profile this site requires. I think we need to establish an extended profile table and keep the extra user fields we already have in it that most people don’t need or want, so they can be selected from, added to, or removed as needed per implementation. Then we can make the default signup form respect the extended field selections.

In addition, I think we could also provide an option for managing users by email address, rather than username. Worthwhile efforts as stepping stones to federated authentication and user management?

Quote from: OpenGeek at May 31, 2005, 06:35 PM

This isn’t really a separate app, just the default profile this site requires.? I think we need to establish an extended profile table and keep the extra user fields we already have in it that most people don’t need or want, so they can be selected from, added to, or removed as needed per implementation.? Then we can make the default signup form respect the extended field selections.

In addition, I think we could also provide an option for managing users by email address, rather than username.? Worthwhile efforts as stepping stones to federated authentication and user management?

Ok, sounds cool. I’ll see about extending TV-like functionality to other system resources. This will allow users to extend the functionality of every resource withing the CMS

I’d vote for the user/authentication consisting of not much more than a username, email, password, and privelleges/roles. Everything else should be dumped into a customizable/extentable/compactable "address book" app for lack of a better description. Even then, the beauty is that the plugin architecture will allow you to override the login to use your own system... Raymond, want to post that flat file authentication again? Other thoughts?

I agree. Imagine a plugin built to either extend the ModX user table or interface with external apps, where you simply had to enter the db info, table and field info for user data, and it took care of syncing everything. You’d still maybe have to do some work to handle logins for different apps, but this would get you a good bit of the way.

Quote from: rthrash at Jun 01, 2005, 03:01 AM

... Even then, the beauty is that the plugin architecture will allow you to override the login to use your own system... Raymond, want to post that flat file authentication again? Other thoughts?

Well I think I will not post the flatfile authentication plugin until after TP3. The flatfile plugin will also demonstrate how you can integrate modx with external authentification systems such as tyour own customized user manager, LDAP, etc.