Verified fixed.

New release dropped, closing.

"full steam ahead" from my side. No outstanding issues.

@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?

Sounds like it could have been this commit that fixes this behavior:

https://github.com/horde/horde/commit/cc36df08d3aef06b72b00831ed82384f7e38461a

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.

Hi Michael,

thanks for going through all my recent bug reports. I highly appreciate that.
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]
"""
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

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).

I don't see exactly the same issue, but something wonky is definitely 
going on.

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.

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!

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.