[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