[dev] turba-git prefs

[Ronan SALMON]

Michael Rubinsky <mrubinsk at horde.org> a écrit :

> Quoting Ronan SALMON <rsalmon at mbpgroup.com>:
>
>>
>> Hi,
>>
>> I'm trying to set prefs 'addressbooks' to use backend 'localsql'.
>>
>> I gave up trying to set this pref through hooks.
>>
>> Here is my prefs.local.php :
>> $_prefs['addressbooks']['value'] = json_encode(array('localsql',  
>> 'localldap', 'favourites'));
>>
>> The backend 'localsql' is configured using default settings (backends.php).
>>
>> I've deleted all prefs (ie: mysql> delete from horde_prefs;)
>>
>> When a user logs in, user's private address book is never available.
>
> As explained in http://bugs.horde.org/ticket/9728 you can't use  
> the'localsql' in the prefs to represent that source when using  
> shares. The $cfgSource array, which holds all address book  
> configuration is populated dynamically with each user's shares  
> during Turba's application initialization, i.e., 'localsql' will  
> *never* represent any available address book when using shares.

I wanted to start from scratch with setting up turba using a setup as  
simple as possible, no hook.

But, reading your comment, I understand now that I've been misled by  
comments in turba/config/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 backends.php (e.g. "localsql").
// You can provide default values this way:
//   'value' => json_encode(array('source_one', 'source_two'))

There are a few comments/examples making references to backend  
'localsql'. This is really confusing me.

Also, the use of backend 'localsql' in prefs.php was working in  
previous version of turba.

> Have you tried moving the code you were using into the new hook that  
> Michael Slusarz added? The code that was provided to you that gives  
> you an accurate list of available address book sources was correct.  
> The time that the code was being executed, however, was not correct  
> (it was too early in the application start up process). The new hook  
> should be called late enough to make this possible.

No, I haven't try the new hooks yet.

Thanks,
Ronan.