Ticket #765 (assigned enhancement)

Opened 8 years ago

Last modified 7 years ago

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

Reported by: spector@zeitgeist.com Assigned to: stevenstremciuc (accepted)
Priority: normal Milestone:
Component: module - user Severity: feature request
Keywords: Cc:

Description

I am looking to use seagull as the basis for a rather large web application. However, I have (not so) small problem... the data in the user table is incomplete. For my application the user needs to be able, at a miniumum, enter at least two kiods of contact info (home and work) Optimally even more.

perhaps whats needed is the ability for the admin to define new fields and have them be able to show up on the new account/signup form...

for example, in my new app, I would like to get the users home AND work data; I would alos like the user to be able to provide other data such as alternate email adresses, SMS addresses, AIM, etc.

As my app grows there will be more...

what I am is concerne about is adding these to my verion of Seagull and then going through hell when I want to upgrade...

Attachments

20060530_add_user_attribute_mgr.diff (26.7 kB) - added by stevenstremciuc on 05/31/06 01:37:11.
db schema changes + user attribute mgr

Change History

03/17/06 21:42:38 changed by demian

  • priority changed from high to normal.
  • summary changed from Request: expand user table data, or brake it ot into a new sub-tables to hold exmapnded user data to 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 :-)

03/17/06 21:43:56 changed by demian

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 :-)

03/20/06 03:30:02 changed by aj

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.

03/20/06 03:43:24 changed by aj

  • owner changed from somebody to aj.
  • status changed from new to assigned.

03/20/06 13:57:06 changed by demian

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

05/13/06 18:51:51 changed by stevenstremciuc

  • owner changed from aj to stevenstremciuc.
  • status changed from assigned to new.

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.

05/13/06 18:51:59 changed by stevenstremciuc

  • status changed from new to assigned.

05/30/06 18:26:36 changed by stevenstremciuc

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?

05/31/06 01:37:11 changed by stevenstremciuc

  • attachment 20060530_add_user_attribute_mgr.diff added.

db schema changes + user attribute mgr

06/04/06 05:49:24 changed by demian

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.

08/12/06 03:29:25 changed by demian

  • milestone deleted.