[dev] turba-git prefs

[Michael M Slusarz]

Quoting Michael Rubinsky <mrubinsk at horde.org>:

> Quoting Ronan SALMON <rsalmon at mbpgroup.com>:
>
>> Michael Rubinsky <mrubinsk at horde.org> a écrit :
>>
>>> Quoting Ronan SALMON <rsalmon at mbpgroup.com>:
>>>
>>>>
>>>> Michael Rubinsky <mrubinsk at horde.org> a écrit :
>>>>
>>>>> Quoting Ronan SALMON <rsalmon at mbpgroup.com>:
>>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>> Yeah, good point. We should tweak the text in that file.  
>>>>> "localsql" will work, but only if it is not being backed by  
>>>>> shares...as was the defaults in earlier versions of Horde, hence  
>>>>> the reason that using 'localsql' worked for you in the past.
>>>>
>>>> In the previous version I'm currently running, this is working  
>>>> like a charm :
>>>> $cfgSources['localsql']['use_shares'] = true;
>>>> $_prefs['addressbooks']['value'] = "localsql\nfavourites\nlocalldap";
>>>
>>> Out of curiousity, what versions of Horde/Turba is this? I have  
>>> *no* idea how this could ever work, as the key 'localsql' never  
>>> represents a single address book when using shares, except maybe  
>>> in a very early, buggy, implementation of share support in Turba.  
>>> In your case, this *always* maps to the user's default address  
>>> book? Do your user's have multiple Turba shares? Not in front of  
>>> the code at the moment, but really no idea what's going on if  
>>> that's the case, and I wrote most of that code :)
>>
>> The version working with the key 'localsql' was pulled from CVS  
>> around October 2008
>>
>> What do you mean by "multiple Turba shares"? multiple shared  
>> backend? Or multiple address book within backend 'localsql'? if the  
>> later, yes a user can create multiple personal address books and  
>> share them.
>
> The following works for me in Turba_Hooks:
>
> <code>
>     public function pushapp_post()
>     {
>         $GLOBALS['prefs']->setValue('addressbooks',  
> json_encode(array_keys(Turba::getConfigFromShares(Turba::availableSources()))), array('nosave' =>  
> true));
>     }
>
> </code>
>
> This will force all address books for the user to be added to the  
> addressbooks pref.

The only issue with this is that pushapp_post() will be called *every*  
time Turba is pushed on the stack.  Turba might be pushed on the stack  
3-4 time on a page access.

This is why postauthenticate *would* be a better place to do this  
since it is only called the first time an application is initialized.   
But after mentioning this a few days ago, I realize this method also  
has one drawback - it doesn't work for the application that provides  
initial authentication to Horde.  This is because postauthenticate  
could potentially alter the auth credentials, so we only initialize  
our prefs AFTER postauthenticate is run since prefs will be reliant on  
the auth credentials to initialize.

So it unfortunately seems like we need (yet) another hook that is run  
once after ab application is authenticated to and its entire  
environment has been initialized.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]