[Tickets #13865] Re: Application settings for "horde" application not updatable in IMAP/Kolab back-end

[noreply at bugs.horde.org]

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-02-17 16:06) hat geschrieben:

Hi Thomas,
> Hi Jens,
>
> I haven't used the Kolab-based prefs backend myself.

ups - I saw you mentioned as author in various files of the Kolab  
sub-module, hence me contacting you...

> To continue the debugging route, I would try to pin down
> *why* the previous XML data stream is empty. For some reason
> it probably didn't find the Kolab XML attachment or ignored it.

Unfortunately, I'm unfamiliar with the inner workings of Horde. I  
wasn't able to spot the code where the $object from  
Horde_Kolab_Storage_Data_Base->modify() (which looks good in my trace,  
in all cases) is to be transformed into the "stream" that later is  
read in Horde_Kolab_Format_Xml_Parser->parse()

Do you have a hint for me, where I should add my next Horde::debug() call?

> As you say storing and loading prefs for other applications work,
> do you see any obvious difference in the generated XML data on the  
> IMAP server?

The XML generated on initial configuration looks good. The only  
noticeable difference is that the XML for application:horde is stored  
base64-encoded:

Content-Type: application/x-vnd.kolab.h-prefs; name=kolab.xml
Content-Disposition: inline; x-kolab-type=xml; filename=kolab.xml
Content-Transfer-Encoding: base64

while all other configuration objects are stored as

Content-Type: application/x-vnd.kolab.h-prefs; name=kolab.xml
Content-Disposition: inline; x-kolab-type=xml; filename=kolab.xml
Content-Transfer-Encoding: quoted-printable

But I haven't seen any immediate clue in the base64-decoded XML as of  
*why* this might be required.

Nevertheless, $object does carry what looks to me like a valid config  
(non-XML, of course) in Horde_Kolab_Storage_Data_Base->modify(), for  
all calls (imp/horde/...) alike.

Regards,
Jens