DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.
Ticket URL: http://bugs.horde.org/ticket/?id=5434
-----------------------------------------------------------------------
Ticket | 5434
Updated By | pdmckone at engmail.uwaterloo.ca
Summary | compose.php breaks when "Expand Names" finds no results
Queue | IMP
Version | 4.1.3
Type | Bug
State | Feedback
Priority | 1. Low
Owners |
-----------------------------------------------------------------------
pdmckone at engmail.uwaterloo.ca (2007-06-05 13:47) wrote:
My tracking trail was:
1) Commented out IMP::status in templates/compose/compose.inc
Problem went away, but so did notification (as expected)
Reinstated IMP::status
2) Commented out notification->push(...) in _expandAddresses in
compose.php
Problem also went away.
Reinstated notification->push(...)
3) Commented out notification->notify(...) in lib/IMP.php
Problem went away.
Reinstated notification->notify(...)
4) Changed parameters of notification->notify(...) to array('listeners' =>
'audio')
Problem went away.
5) Changed parameters of notification->notify(...) to array('listeners' =>
'status')
Problem persisted.
Reinstated parameter of array('listeners'=>array('status', 'audio')
I reasoned that the problem was being introduced by the call to "push" but
not tripped until the call to "notify", so went looking for other examples
of notification->push, and found that they were all either strings, or
calls to result->getMessage(), which led me to think "aha".
Further exploration:
If I enter "zyxw" as the address to expand (knowing that it doesn't exist
in either of our addressbooks), the result that is returned by
_expandAddresses' call to IMP::expandAddresses(_getAddressList($header,
true), true) is :
PEAR_Error Object
(
[error_message_prefix] =>
[mode] => 1
[level] => 1024
[code] =>
[message] => Please resolve ambiguous or invalid addresses.
[userinfo] => Array
(
[0] => PEAR_Error Object
(
[error_message_prefix] =>
[mode] => 1
[level] => 1024
[code] =>
[message] =>
[userinfo] => zyxw
[backtrace] => Array
(
[0] => Array
(
[file] =>
/usr/local/share/pear/PEAR.php
[line] => 572
[function] => PEAR_Error
[class] => PEAR_Error
[type] => ->
[args] => Array
(
[0] =>
[1] =>
[2] => 1
[3] => 1024
[4] => zyxw
)
)
[1] => Array
(
[file] =>
/usr/local/www/horde_exp3/imp/lib/IMP.php
[line] => 417
[function] => raiseError
[class] => PEAR
[type] => ::
[args] => Array
(
[0] =>
[1] =>
[2] =>
[3] =>
[4] => zyxw
)
)
[2] => Array
(
[file] =>
/usr/local/www/horde_exp3/imp/compose.php
[line] => 102
[function] => expandAddresses
[class] => IMP
[type] => ::
[args] => Array
(
[0] => zyxw
[1] => 1
)
)
[3] => Array
(
[file] =>
/usr/local/www/horde_exp3/imp/compose.php
[line] => 695
[function] => _expandAddresses
[args] => Array
(
[0] => to
)
)
)
[callback] =>
)
)
[backtrace] => Array
(
[0] => Array
(
[file] => /usr/local/share/pear/PEAR.php
[line] => 572
[function] => PEAR_Error
[class] => PEAR_Error
[type] => ->
[args] => Array
(
[0] => Please resolve ambiguous or invalid
addresses.
[1] =>
[2] => 1
[3] => 1024
[4] => Array
(
[0] => PEAR_Error Object
(
[error_message_prefix] =>
[mode] => 1
[level] => 1024
[code] =>
[message] =>
[userinfo] => zyxw
[backtrace] => Array
(
[0] => Array
(
[file] =>
/usr/local/share/pear/PEAR.php
[line] => 572
[function] =>
PEAR_Error
[class] =>
PEAR_Error
[type] => ->
[args] =>
Array
(
[0] =>
[1] =>
[2] =>
1
[3] =>
1024
[4] =>
zyxw
)
)
[1] => Array
(
[file] =>
/usr/local/www/horde_exp3/imp/lib/IMP.php
[line] => 417
[function] =>
raiseError
[class] =>
PEAR
[type] => ::
[args] =>
Array
(
[0] =>
[1] =>
[2] =>
[3] =>
[4] =>
zyxw
)
)
[2] => Array
(
[file] =>
/usr/local/www/horde_exp3/imp/compose.php
[line] => 102
[function] =>
expandAddresses
[class] =>
IMP
[type] => ::
[args] =>
Array
(
[0] =>
zyxw
[1] =>
1
)
)
[3] => Array
(
[file] =>
/usr/local/www/horde_exp3/imp/compose.php
[line] => 695
[function] =>
_expandAddresses
[args] =>
Array
(
[0] =>
to
)
)
)
[callback] =>
)
)
)
)
[1] => Array
(
[file] => /usr/local/www/horde_exp3/imp/lib/IMP.php
[line] => 464
[function] => raiseError
[class] => PEAR
[type] => ::
[args] => Array
(
[0] => Please resolve ambiguous or invalid
addresses.
[1] =>
[2] =>
[3] =>
[4] => Array
(
[0] => PEAR_Error Object
(
[error_message_prefix] =>
[mode] => 1
[level] => 1024
[code] =>
[message] =>
[userinfo] => zyxw
[backtrace] => Array
(
[0] => Array
(
[file] =>
/usr/local/share/pear/PEAR.php
[line] => 572
[function] =>
PEAR_Error
[class] =>
PEAR_Error
[type] => ->
[args] =>
Array
(
[0] =>
[1] =>
[2] =>
1
[3] =>
1024
[4] =>
zyxw
)
)
[1] => Array
(
[file] =>
/usr/local/www/horde_exp3/imp/lib/IMP.php
[line] => 417
[function] =>
raiseError
[class] =>
PEAR
[type] => ::
[args] =>
Array
(
[0] =>
[1] =>
[2] =>
[3] =>
[4] =>
zyxw
)
)
[2] => Array
(
[file] =>
/usr/local/www/horde_exp3/imp/compose.php
[line] => 102
[function] =>
expandAddresses
[class] =>
IMP
[type] => ::
[args] =>
Array
(
[0] =>
zyxw
[1] =>
1
)
)
[3] => Array
(
[file] =>
/usr/local/www/horde_exp3/imp/compose.php
[line] => 695
[function] =>
_expandAddresses
[args] =>
Array
(
[0] =>
to
)
)
)
[callback] =>
)
)
)
)
[2] => Array
(
[file] => /usr/local/www/horde_exp3/imp/compose.php
[line] => 102
[function] => expandAddresses
[class] => IMP
[type] => ::
[args] => Array
(
[0] => zyxw
[1] => 1
)
)
[3] => Array
(
[file] => /usr/local/www/horde_exp3/imp/compose.php
[line] => 695
[function] => _expandAddresses
[args] => Array
(
[0] => to
)
)
)
[callback] =>
)
I noted that there was an message string within the object, so thought
"that's what I'm trying to get at." (I'm not really familiar with the
PEAR_Error format, but it struck me as odd that there appeared to be an
PEAR_Error within a PEAR_Error.)
Looking at the code for push, I can see that it's meant to be handling
PEAR_Error objects, so the getMessage() suggestion is more of a repair
than a resolution.
Drilling down through the code, adding 'print_r()'s and 'echo "gets
here"'s, I note that notify in Notification/Listener/status.php calls
getMessage in the same file, which in turn relies on getEvent from
Notification/Listener.php. getEvent calls getUserInfo and then implodes
the result to add to the $ob->_message variable. This seems to fail for
this particular PEAR_Error, where the ['event']['userinfo'] is an array
containing another array.
I don't know the purpose of the $ob_message variable, so I can't say
whether the solution might be to change the implode() to a serialize() --
just to capture the data.
I suspect the real problem is that the routine that expands the addresses
passes the results from the first search on to the second (we search both
an SQL MyAddressBook, and a campus-wide LDAP), and when an address isn't
found in either, passes the Error-within-an-Error on through to notify,
which then fails.
I'd have to figure out how to track back into IMP.php's expandAddresses to
see if I can figure out what the contacts/search routines pass for searches
of multiple addressbooks.
Ah! After much fiddling and tracking:
The routine expandAddresses in lib/IMP.php returns
PEAR::raiseError(_("Please resolve ambiguous or invalid
addresses."), null, null, null, $arr);
if nothing is found, and that's where the PEAR_Error is introduced into
the userinfo field, via the $arr variable. Would it be better to use the
$addrString that was passed in? i.e.:
PEAR::raiseError(_("Please resolve ambiguous or invalid
addresses."), null, null, null, $addrString);
or perhaps rebuild the original contents of the $arr array with:
$arr = MIME::rfc822Explode($addrString, ',');
$arr = array_map('trim', $arr);
$arr = array_filter($arr);
return PEAR::raiseError(_("Please resolve ambiguous or invalid
addresses."), null, null, null, $arr);
This latter seems to solve the problem, but still may not be ideal. The
real solution is likely in not putting the PEAR_Error into $arr in the
first place. But that'll take more searching.