Closing since this is not a bug, and this request is doable already by 
not using shares.

They may be useless and redundant on *your* installation...
Just because there is a "not shared" source doesn't necessarily mean 
that it should be treated as the user's one and only personal, address 
book.
Well, that's your prerogative and is certainly reasonable.  FYI, Horde 
3.2 and Turba 2.2 will allow you to disallow users from setting 
permissions on their shares.
I don't see why you shouldn't be able to just copy the records from 
one table to the other without any problems, assuming both tables have 
the same structure. Otherwise, yea, your right, you would need a 
script to map the fields of one to the other.
That's reasonable.
Any address book that is created either automatically, or by the user, 
will automatically be appended to this pref.  It is up to the user to 
remove it if he/she desires.



...but this leads me to another question.  You say above that you want 
your users to be *able* to create and share address books, yet you set 
the backend that contains the users' address books to *not* use 
shares...and you stated that you don't want the users to be able to 
create any address books in the same table as the company address book 
- which is the one you enabled shares on. So, my question is - where 
are the users going to create the new address books?  After you decide 
which source will contain them, you must put that value into the 
$conf['shares']['source'] setting.  If you decide to put them in 
'localsql' then they will also be able to share the "default" personal 
address book as well.



Another option would have been for you to create the company address 
book as not share enabled and use the permission system to make it 
public or whatever.

All my thanks for your clear, fast and complete answer



Summary of my answer

I continue to think that each user requires for one and ONLY ONE 
personal address book and that this address book does not have to be 
shared (shareable?), because it can contain personal addresses like 
addresses of the family members.

Although I never yet configured turba with several shared sources, I 
think that the solution that you plan, to put a new parameter in 
sources.php defining for each shared source if it is necessary to 
create a personal address book in this source for each user, is a very 
flexible and satisfactory solution for a maximum of different uses of 
turba.

This parameter could be named :

'create_personnal_addressbook_in_this_source' => false |  true

This parameter being used only when this source is shared

This parameter could be positioned with  "false" for all the shared 
sources when the personal address books of the users are placed on a 
not shared source

I prefer this solution compared to the solutions which I had proposed 
that I find less flexible.



Details of my answer

With your respect, I do not think that the goal of the code is to 
create useless and redundant address books but I understand that it is 
essential to create a personal address book for each user on one (and 
I think only one) shared source when the administrator did not define 
a not shared source.

I am not favorable to this solution for several reasons



I think that the personal address books, containing private data,   
should not be shared nor even shareable.



This solution makes unusable the not shared source, since a shared 
source exists, and requires to use a script to transform the address 
books of all the users existing on the not shared source into address 
books on the shared source (I do not think that this script - who 
would however be essential for this handling - already exists).



I prefer to maintain the address book of the company which is 
generated automatically on a distinct table corresponding to a 
distinct shared  source on which the users cannot create address book

To lock this parameter would be a degraded solution because I wish 
nevertheless to allow the users to create shared address books

It is an error of me, I thought that this parameter indicated the 
source where was the personal address book of each user and that it 
was thus possible to know the source where the personal address book 
of each user was
I think however that it is the best solution because it does not 
withdraw any functionality and adds flexibility without imposing 
anything



Respectful greetings

This is the expected behaviour of our current code. It ensures that 
each user has a personal addressbook created for them automatically.
Why not use the same source for all the address books?  Each user will 
have his/her own personal address book, and the admins can still 
create additional address books as they do now.
According to your prefs.php entry below, the pref is not locked, so 
this is expected, the user's default address book for any share would 
automatically be created, and added to the pref.  If you want to 
prevent any changes to the pref, set it to be locked.
Are you using an external application that makes use of the client 
api?  If not, you do not need to set this...and if you *are* using 
one, setting it to a source that contains only private address books 
means that each user will only see their own personal address books as 
clients - not really what the clients api was designed for.
Again, this doesn't make sense to me.  Why would you use a non-shared 
source for the clients source?  The clients setting is designed for 
designating a source to be used when external applications need to 
interface with "client" data - such as a time tracking, billing 
application etc...
What I see as the underlying question here is - do we want to 
automatically create a default address book in each share-enabled 
source if there is already a visible address book in that source.  I 
can see the argument for this both ways.  First, if we *don't* create 
it, then for people that are using only one, share-enabled backend, 
this means that any newly added users will have to create their own 
personal address books if there are already any existing address books 
he/she can see.  I can see how a config setting might be useful here, 
but this would come with it's own issues.  For example, if an 
installation uses two different backends, similar to yours, but both 
have shares enabled.  This would prevent the automatic creation of 
personal address books on *any* of the backends - even if it is 
desired.  The other option is to introduce a new config param in 
sources.php to configure this per source, but we are trying to reduce 
the number of configuration settings, not increase them.



I really don't know the best answer here and am open to more 
suggestions that would work across most of Turba's use cases.

Description of the problem

With the new version of turba (2.2-RC1), a new useless and redundant 
personal address book is created for each user at the time of the 
access to the address book .

This new address book is created in the shared sql source, whereas a 
personal address book already exists in the source by defect which is 
not shared

Moreover, this address book appears in the drop-down list of the 
address books for each user, even if it does not appear in the list of 
the address books to propose by defect defined in prefs.php



Context

The sources are configured as follows:

localsql: not shared source where the personal address books of all 
the users are, it corresponds to the table turba_objects.

companysql: shared source created by administrator, accessible in 
reading only by the users and update automatically, it corresponds to 
the table company_addresses



Details of turba configuration files

conf.php

...

$conf['client']['addressbook'] = 'localsql';

$conf['shares']['source'] = '';

...



sources.php

...

$cfgSources['localsql'] = array(

     'title' => _("My Address Book"),

     'type' => 'sql',

     'params' => array_merge($GLOBALS['conf']['sql'], array('table' => 
'turba_objects')),

...

    'use_shares' => false,

...

$cfgSources['companysql'] = array(

     'title' => 'All addresses of the company',

     'type' => 'sql',

     'params' => array_merge($GLOBALS['conf']['sql'], array('table' => 
'company_addresses')),

...

    'use_shares' => true,

...



prefs.php

...

// Address books to be displayed in the address book selection widget

// and in the Browse menu item.  The address book name is stored using

// the source key from sources.php (e.g. "localsql").  Separate

// entries with "\n" , e. g. 'value' => "localsql\nlocalldap" (the

// double quotes are REQUIRED).  If 'value' is empty (''), all address

// books that the user has permissions to will be listed.

$_prefs['addressbooks'] = array(

     'value' => "localsql\ncompanysql:dfa9fb2a5981046059df70cf42141012",

     'locked' => false,

     'shared' => false,

     'type' => 'implicit',

);

...



Considered solutions

1 - When the source of the clients personal address books is not 
shared, do not create a personal address book in the shared source if 
a shared source exists



or



2 - Define a new parameter in conf.php allowing to choose if it is 
necessary or not to create automatically  a personal address book in 
the shared source for each user ; for example:

$conf['client']['create_automatically_addressbook_in_share_source'] = false;



greetings