Summary | not getting free/busy info from right source |
Queue | Kronolith |
Queue Version | Git master |
Type | Bug |
State | Not A Bug |
Priority | 1. Low |
Owners | |
Requester | rsalmon (at) mbpgroup (dot) com |
Created | 02/11/2010 (5637 days ago) |
Due | |
Updated | 04/05/2010 (5584 days ago) |
Assigned | 03/17/2010 (5603 days ago) |
Resolved | 04/05/2010 (5584 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
State ⇒ Feedback
* Any preference that is NOT LOCKED, that is set by a hook, WILL BE SAVED
* WITH THAT VALUE. This means:
* 1) Users will get the results of the hook set for them in their
* preferences.
* 2) The next time they login and load their preferences, the hook will NOT
* be called. However, if the preference is locked, the result of the hook
* will never be saved.
From my previous post, If I lock the pref (and hook is enabled),
Kronolith crashes. This can't be the expected behavior.
$_prefs['search_sources'] = array(
'value' => "",
'locked' => true,
'hook' => true,
'shared' => false,
'type' => 'implicit',
);
State ⇒ Not A Bug
function prefs_hook_search_sources($username = null) {
if (!$username) {
return;
}
if ($GLOBALS['registry']->hasMethod('contacts/sources')) {
$sources = $GLOBALS['registry']->call('contacts/sources');
return implode("\t", array_keys($sources));
}
}
and configured the following pref to get 'search_sources' set
automatically when a (new/old) user logs in :
$_prefs['search_sources'] = array(
'value' => "",
'locked' => false,
'hook' => true,
'shared' => false,
'type' => 'implicit',
);
If I set locked to true, kronolith doesn't not work anymore :
exception 'Kronolith_Exception' with message 'No calendar driver
specified' in /var/www/html/horde/kronolith/lib/Kronolith.php:2209
Stack trace: #0 /var/www/html/horde/kronolith/lib/Kronolith.php(432):
Kronolith::getDriver()
#1/var/www/html/horde/kronolith/lib/View/Week.php(73):
Kronolith::listEvents(Object(Horde_Date), Object(Horde_Date))
#2/var/www/html/horde/kronolith/lib/Kronolith.php(2267):
Kronolith_View_Week->Kronolith_View_Week(Object(Horde_Date))
#3/var/www/html/horde/kronolith/week.php(15): Kronolith::getView('Week')
#4{main}If I set locked to false, a pref is added in table [horde_prefs] :
rsalmon | kronolith | search_sources |
e35b32a27eb8a6ecba9d64c5ede2c288 localldap favourites
From there, kronolith is able to look up attendee's availability.
Though, the hook doesn't work as I would expect : the idea of
prefs_hook_search_sources is to create, on the fly, a list of all
possible available address books for the current session.
The first time a user logs in, the hook is kicked off and that's it.
The next time the user logs in, kronolith seems to be checking first
if user pref 'search_sources' exists, and if not, reads what's in
prefs.php
Is this a bug or is this the expected behaviour ?
The search_sources preference is responsible for determining the
address books that are searched for free/busy urls.
turba $_prefs['addressbooks']['value'] is empty
when adding attendees, I clicked on 'Address book', selected LDAP
source and selected a user.
State ⇒ Feedback
The search_sources preference is responsible for determining the
address books that are searched for free/busy urls.
Milestone ⇒
State ⇒ Unconfirmed
Patch ⇒ No
Queue ⇒ Kronolith
Summary ⇒ not getting free/busy info from right source
Type ⇒ Bug
Priority ⇒ 1. Low
1 - user's personal address book (MySQL) : empty
2 - global address book (LDAP) : about 50 users
3 - user's favourite recipients (MySQL) : empty
the LDAP address book has the freebusy info.
- With : $_prefs['display_contact']['value'] = 1
Create a new event, add an attendee (a user from LDAP address book) :
I get the following error:
Error retrieving free/busy information for ronan@mbpgroup.com: No
free/busy url found for ronan@mbpgroup.com.
-With : $_prefs['display_contact']['value'] = 0 and change the order
of address book eg, LDAP first and the two other MySQL.
Create a new event, add an attendee (a user from LDAP address book) :
no error and I'm able to see attendee's availability.
it looks like kronolith isn't looking up user's availability using the
right source.