[Tickets #5960] Re: Creation of doubled blooms of the personal address books

[bugs at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://dev.horde.org/horde/whups/ticket/?id=5960
-----------------------------------------------------------------------
 Ticket             | 5960
 Updated By         | Michael Rubinsky <mrubinsk at horde.org>
 Summary            | Creation of doubled blooms of the personal address books
 Queue              | Turba
 Version            | 2.2-RC1
 Type               | Bug
 State              | Assigned
 Priority           | 2. Medium
 Owners             | Michael Rubinsky
-----------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2007-12-05 08:07) wrote:

> 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 is the expected behaviour of our current code. It ensures that each
user has a personal addressbook created for them automatically.

> 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

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.

> 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

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.

> $conf['client']['addressbook'] = 'localsql';
> $conf['shares']['source'] = '';

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.

> 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

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...

> 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;

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.