| Summary | compose.php breaks when "Expand Names" finds no results |
| Queue | IMP |
| Queue Version | 4.1.3 |
| Type | Bug |
| State | Duplicate |
| Priority | 1. Low |
| Owners | |
| Requester | pdmckone (at) engmail (dot) uwaterloo (dot) ca |
| Created | 06/04/2007 (6616 days ago) |
| Due | |
| Updated | 06/07/2007 (6613 days ago) |
| Assigned | 06/04/2007 (6616 days ago) |
| Resolved | 06/07/2007 (6613 days ago) |
| Github Issue Link | |
| Github Pull Request | |
| Milestone | |
| Patch | No |
the dates on 4744, I'm about 6 months behind in tracking this down.
Thanks for your help. We'll get hold of 3.1.4.
PDM
what Horde version are you using? If you're not using 3.1.4, then this
is a duplicate of
bug 4744.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.
State ⇒ Feedback
nothing in IMP::status reads from the notification stack that I can
see. It's possible this was fixed in 4.1.4, but I don't see anything
likely in the changelog.
So, can you poke a bit more to see where this is really happening? Thanks!
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ compose.php breaks when "Expand Names" finds no results
Queue ⇒ IMP
State ⇒ Unconfirmed
(throwing a PEAR_Error), the compose window reloads with only the
header "Message Composition", followed by a line break.
It appeared to be the IMP::status call in
templates/compose/compose.inc that was failing. I think it's because
the line in compose.php's _expandAddresses function:
$GLOBALS['notification']->push($error, 'horde.warning');
should be:
$GLOBALS['notification']->push($error->getMessage(), 'horde.warning');
so that it's pushing just the error message rather than the whole
PEAR_Error object.
I've edited my compose.php, and resolved the problem on my setup.
PDM