[dev] [cvs] commit: turba/scripts/sql turba_objects.mssql.sql turba_objects.mysql.sql turba_objects.oci8.sql turba_objects.pgsql.sql turba_objects.sql turba/scripts/upgrades 2007-08-05_remove_lastname_null_constraint.sql turba/config attributes.php.dist sources.php.dist

[Chuck Hagenbuch]

Quoting Michael Rubinsky <mike at theupstairsroom.com>:

>> I think I finally understand the problem here, it's when you name a
>> new contact list, and so you're not using the backend's fields.
>
> Yep, contact list names seem to be stored in the 'name' field - but   
> since in our default schema, it's a composite field, it attempts to   
> get parsed into a firstname and lastname etc...
>
>
> What
>> about just adding a simple setting to backends named
>> "contact_name_field" or some such which specifies which name field (if
>> it's not "name") should be used when naming contact lists?
>
> Sure...then just map the 'contact_name_field' back to 'name' when  
> it's  displayed, right?  Seems simple enough, but I thought we were  
> trying  to avoid more parameters in the config array though?

In general, yes, but this seems like a case where having a config  
setting would simplify things, instead of adding complexity.

-chuck