[dev] turba-git prefs

[Michael Rubinsky]

Quoting Michael M Slusarz <slusarz at horde.org>:

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

This would be fine in *this* case, since Turba doesn't provide  
authentication to horde anyway. That being said, and I'm not able to  
reproduce this ALL the time, but I occasionally get a fatal error  
about $GLOBALS['prefs']->setValue() calling a method on a non-object.

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

Sounds like a good solution.

>
> michael
>
> ___________________________________
> Michael Slusarz [slusarz at horde.org]
>
> -- 
> Horde developers mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org


mike

The Horde Project (www.horde.org)
mrubinsk at horde.org