Thu, 09 Apr 2026 20:04:43 +0000 https://bugs.horde.org/ticket/14201 Saving of Kolab XML objects with non-7bit elements fails There is an issue with saving Kolab XML objects containing non-7bit characters. A work-around patch is provided with this bug report, but the solution probably needs a second look. For details, see description in patch header. Wed, 16 Dec 2015 15:18:02 +0000 https://bugs.horde.org/ticket/14201#t89172 I can confirm that this resolved a long-standing issue in the Kolab back-end. @Michael: if "prio low" means this isn't included in a short-term update of the PEAR packages, I totally disagree: Horde war absolutely broken, modifying any appointment etc. was impossible for us without this patch and it of course affected synching back items from mobiles etc. THIS IS A VERY IMPORTANT FIX. @Mike: Good work, thank you! Fri, 18 Dec 2015 12:19:10 +0000 https://bugs.horde.org/ticket/14201#t89226 > I can confirm that this resolved a long-standing issue in the Kolab back-end. > > @Michael: if "prio low" means this isn't included in a short-term > update of the PEAR packages, I totally disagree: Horde war absolutely > broken, modifying any appointment etc. was impossible for us without > this patch and it of course affected synching back items from mobiles > etc. THIS IS A VERY IMPORTANT FIX. Priority Low means just that, it's not high priority. It has nothing to do with the version that any potential fix will appear in. It's just not high on any developer's personal @todo list. If this, or any other issue, is critical to *you*, consider sponsoring development time to work it. Mon, 28 Dec 2015 22:06:26 +0000 https://bugs.horde.org/ticket/14201#t89276 I don't see exactly the same issue, but something wonky is definitely going on. Mon, 28 Dec 2015 22:14:22 +0000 https://bugs.horde.org/ticket/14201#t89277 Can you please give some more detail as to *exactly* what is failing with non 7-bit characters? With the "double decoding" patch applied, I don't have any issues when saving/editing/syncing data containing 8bit data (and thus base64 encoded in the imap message). Tue, 29 Dec 2015 04:10:50 +0000 https://bugs.horde.org/ticket/14201#t89281 Hi Michael, thanks for going through all my recent bug reports. I highly appreciate that. > Can you please give some more detail as to *exactly* what is failing > with non 7-bit characters? I just realize, I was a bit unclear about the history of debugging this issue with all my previous posts on this bug report. Sorry for that. In the course of things, my first observation was: o disable Horde caching o Create an event (or task, or memo, ...) without umlauts o Save the event (-> ok) (here as quoted-printable attachment) o Edit the event, add an umlaut into the title or location or whereever. o Save the event (-> event vanishes, at the latest when logging out and in again) Alternatively: o disable Horde caching o Create an event, add an umlaut into the title or location or whereever. o Save the event (-> event vanishes, at the latest when logging out and in again) The above got fixed by the patch provided in #14199. With #14199 fixed, I now can see Kolab groupware objects containing Umlauts. Things looked normal again with Horde caching enabled and disabled. THEN... (coming to this bug)... The next observation was: o Edit an event already containing umlauts (that is now visible, after #14199 has been fixed). Double check that this event is stored as base64 transfer-encoded Kolab XML attachment. o It doesn't matter if you add another umlaut or remove umlauts or whatever. o Save the event (or task, or note, ...) -> results in the below browser notification: """ Failed writing the Kolab object: Failed parsing Kolab object input data of type string! Input was: Æioz»"¢}tzw(v)àQ1|z÷§¶÷«²*'×K¢wžºå?... [shortened to 50 characters] """ > With the "double decoding" patch applied, I don't have any issues > when saving/editing/syncing data containing 8bit data (and thus > base64 encoded in the imap message). The error does not get raised in actually saving the new object. It some gets raised by processing the "previous" object (which is not really handled in the Kolab_Storage code, at all). The issue got also observed by Jens and has been reported as #13865. Jens tested my proposed (work-around) patch and reported success, as well. See communication history of #13865. Hope this extra information helps, Mike Tue, 29 Dec 2015 09:02:19 +0000 https://bugs.horde.org/ticket/14201#t89293 I can't reproduce this issue with the current Git code. However, I can reproduce it with the current stable PEAR package so this has already been fixed in Git. I'm trying to track down the exact commit(s) that fix the issue, but it's definitely no longer happening. Tue, 29 Dec 2015 14:51:05 +0000 https://bugs.horde.org/ticket/14201#t89295 Sounds like it could have been this commit that fixes this behavior: https://github.com/horde/horde/commit/cc36df08d3aef06b72b00831ed82384f7e38461a Tue, 29 Dec 2015 15:30:05 +0000 https://bugs.horde.org/ticket/14201#t89298 @Thomas, Sounds like it's about time the new package gets dropped. Do you have any outstanding issues that need to be addressed before this happens? Tue, 29 Dec 2015 16:51:22 +0000 https://bugs.horde.org/ticket/14201#t89305 > @Thomas, > > Sounds like it's about time the new package gets dropped. Do you have > any outstanding issues that need to be addressed before this happens? "full steam ahead" from my side. No outstanding issues. Tue, 29 Dec 2015 18:23:17 +0000 https://bugs.horde.org/ticket/14201#t89308 Verified fixed. New release dropped, closing. Sat, 02 Jan 2016 20:14:36 +0000 https://bugs.horde.org/ticket/14201#t89314