Request: expand user table data, or break it into a new sub-tables to hold expanded user data

yep, this is a pretty popular request, quite easy to do as well. current user table needs one additional field, 'is_extended', and if that contains a non-zero value, then the value it contains will be a foreign key to a pivot table:

usr ================ is_extended | 23

user_custom_attribute_name ========================== id | 1 name | work_email_address

user_custom_attribute_value =========================== user_extended_id | 23 custom_attribute_id | 1 custom_attribute_value | 'foo@bar.com'

patches welcome :-)

yep, this is a pretty popular request, quite easy to do as well. current user table needs one additional field, 'is_extended', and if that contains a non-zero value, then the value it contains will be a foreign key to a pivot table:

usr
================
is_extended | 23

user_custom_attribute_name
==========================
id | 1
name | work_email_address

user_custom_attribute_value
===========================
user_extended_id | 23 
custom_attribute_id  | 1
custom_attribute_value | 'foo@bar.com'

patches welcome :-)

I propose removing contact information completely from the usr table and the creation of a ContactMgr? and LocationMgr? which will manage Contact (phone, mobile, fax, aim, msn, etc) and Location (address1, address2, address3, city, state, zip, country) information respectively. There would also be the need for a ContactTypeMgr? which allow for the creation of different types (work, home, etc). I've already done this it's just a matter of porting it to trunk btw.

Hi again AJ - this is an interesting suggestion but I think on a different topic to what spector is querying. What you're suggesting is a refactoring of Usr into a composite object, and with the location and contact child properties factored into other tables, you're suggesting user data would be more manageable.

I think this is true but it needs to be optional, the amount of joins and additional complexity in the data structure will not suit everyone.

What spector is suggesting is something however that almost every seagull user needs: the ability to add custom properties to Usr and not loose them after upgrades. My suggestion which is simple to implement would solve this shortcoming.

cheers

Demian

AJ,

What Demian suggests is something I need in my project and something I can implement. I will go ahead and submit a patch for this one.

Demian,

I need feedback on my effort so far. Basically, I made the table modifications you recommended, and a attribute mgr that allows add/edit/delete attributes in the user_custom_attribute table. I'm wondering what other helper methods or features would be useful?

db schema changes + user attribute mgr

Hi Steve - as per IRC chat, let's put this on pause for a bit until the cms stuff is progressed a bit, i want to avoid duplication of effort if possible, although i do think your improvements to user flexibility will be best served if they remain separate from any cms stuff.