[Tickets #13865] Re: Application settings for "horde" application not updatable in IMAP/Kolab back-end
noreply at bugs.horde.org
noreply at bugs.horde.org
Thu Mar 5 18:56:34 UTC 2015
BITTE NICHT AUF DIESE NACHRICHT ANTWORTEN. NACHRICHTEN AN DIESE
E-MAIL-ADRESSE WERDEN NICHT GELESEN.
Ticket-URL: https://bugs.horde.org/ticket/13865
------------------------------------------------------------------------------
Ticket | 13865
Aktualisiert Von | jmozdzen at nde.ag
Zusammenfassung | Application settings for "horde" application not
| updatable in IMAP/Kolab back-end
Warteschlange | Kolab
Typ | Bug
Status | Unconfirmed
Priorität | 3. High
Milestone |
Patch |
Zuständige |
------------------------------------------------------------------------------
jmozdzen at nde.ag (2015-03-05 18:56) hat geschrieben:
*** Could someone please give me a helping hand? ***
I have a trace... but am unsure if I'm on the right track.
- ran horde-clear-cache; imp-query-cache (clearing Kolab cache); rm
$tmpdir/cache/horde*;rcapache2 restart
(should have a clean system now)
- log in to Horde, then look at my debug log
I see that Horde_Kolab_Storage_Data_Base:modify() is called, sets the
driver and then calls "$object->save($writer);", which does not throw
an exception
(looking at the IMAP store shows that a new config object for
application "horde" is written)
but Horde_Prefs->store() reports an exception (see below for details)!
I've traced things back to Horde_Kolab_Storage_Cache_Data->store(),
where it's running
if (isset($object['_attachments'])) {
$attachments = array();
Horde::debug($object);
foreach ($object['_attachments'] as $id => $attachment) {
$attachments['id'][] = $id;
if (isset($attachment['name'])) {
$attachments['name'][$attachment['name']][] = $id;
}
if (isset($attachment['type'])) {
$attachments['type'][$attachment['type']][] = $id;
}
$this->_cache->storeAttachment($this->getDataId(), $obid, $id,
$attachment['content']);
}
$object['_attachments'] = $attachments;
}
$this->_data[self::OBJECTS][$object['uid']] = $object;
storeAttachment($data_id, $obid, $attachment_id, $data) calls new
Horde_Stream_Existing(array('stream' => $data)), which throws the
exception
object(InvalidArgumentException)#3389 (7) {
["message":protected]=>
string(23) "Need a stream resource."
["string":"Exception":private]=>
string(0) ""
["code":protected]=>
int(0)
["file":protected]=>
string(46) "/usr/share/php5/PEAR/Horde/Stream/Existing.php"
["line":protected]=>
int(39)
because of the following check:
public function __construct(array $opts = array())
{
if (!isset($opts['stream']) || !is_resource($opts['stream'])) {
throw new InvalidArgumentException('Need a stream resource.');
}
Hence the Horde::debug( $object) in the code snipplet above and I have
debugged the storeAttachment() params, too:
parm1 (data_id) is "35cc31fb3bdf4fb8afc81dba6f09c17a"
parm2 (obid) is 9764
parm3 (attachment_id) is "id"
parm4 (data) is... empty.
The object that is looping over has the following _attachments content:
["_attachments"]=>
array(2) {
["id"]=>
array(3) {
[0]=>
string(27) "Kolab Groupware Information"
[1]=>
string(2) "id"
[2]=>
string(4) "type"
}
["type"]=>
array(2) {
["text/plain"]=>
array(1) {
[0]=>
string(27) "Kolab Groupware Information"
}
["application/octet-stream"]=>
array(2) {
[0]=>
string(2) "id"
[1]=>
string(4) "type"
}
}
}
"id" and "type" have completely different structures, is that intended?
The exceptions call trace is
/usr/share/php5/PEAR/Horde/Kolab/Storage/Cache/Data.php:493
/usr/share/php5/PEAR/Horde/Kolab/Storage/Data/Cached.php:252
/usr/share/php5/PEAR/Horde/Kolab/Storage/Data/Base.php:327
/usr/share/php5/PEAR/Horde/Prefs/Storage/KolabImap.php:141
/usr/share/php5/PEAR/Horde/Prefs.php:439
but I guess the entries are created somewhere else.
HELP!
More information about the bugs
mailing list