6.0.0-git
2021-05-07

[#14201] Saving of Kolab XML objects with non-7bit elements fails
Summary Saving of Kolab XML objects with non-7bit elements fails
Queue Kolab
Type Bug
State Resolved
Priority 1. Low
Owners mrubinsk (at) horde (dot) org, thomas.jarosch (at) intra2net (dot) com
Requester mike.gabriel (at) das-netzwerkteam (dot) de
Created 2015-12-16 (1969 days ago)
Due
Updated 2016-01-02 (1952 days ago)
Assigned 2015-12-29 (1956 days ago)
Resolved 2016-01-02 (1952 days ago)
Milestone
Patch Yes

History
2016-01-02 20:14:36 Michael Rubinsky Comment #11
State ⇒ Resolved
Reply to this comment
Verified fixed.

New release dropped, closing.
2015-12-29 18:23:17 Thomas Jarosch Comment #10 Reply to this comment
@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.

2015-12-29 16:51:22 Michael Rubinsky Comment #9 Reply to this comment
@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?
2015-12-29 16:51:02 Michael Rubinsky Assigned to Thomas Jarosch
 
2015-12-29 15:30:05 Michael Rubinsky Comment #8 Reply to this comment
Sounds like it could have been this commit that fixes this behavior:

https://github.com/horde/horde/commit/cc36df08d3aef06b72b00831ed82384f7e38461a
2015-12-29 14:51:05 Michael Rubinsky Comment #7 Reply to this comment
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.

2015-12-29 09:02:19 mike (dot) gabriel (at) das-netzwerkteam (dot) de Comment #6 Reply to this comment
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
2015-12-29 04:11:04 Michael Rubinsky State ⇒ Feedback
 
2015-12-29 04:10:50 Michael Rubinsky Comment #5 Reply to this comment
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).
2015-12-28 22:16:35 Michael Rubinsky Assigned to Michael Rubinsky
Taken from Michael J Rubinsky <mrubinsk@horde.org>
 
2015-12-28 22:14:22 Michael Rubinsky Comment #4
Assigned to Michael J Rubinsky <mrubinsk@horde.org>
State ⇒ Assigned
Reply to this comment
I don't see exactly the same issue, but something wonky is definitely 
going on.
2015-12-28 22:06:26 Michael Rubinsky Comment #3 Reply to this comment
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.

2015-12-18 12:19:10 jmozdzen (at) nde (dot) ag Comment #2 Reply to this comment
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!


2015-12-16 23:14:35 Michael Rubinsky Priority ⇒ 1. Low
 
2015-12-16 15:18:02 mike (dot) gabriel (at) das-netzwerkteam (dot) de Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 3. High
Summary ⇒ Saving of Kolab XML objects with non-7bit elements fails
Queue ⇒ Kolab
Milestone ⇒
Patch ⇒ Yes
New Attachment: 1003_Kolab_no-previous-object-storing.patch Download
Reply to this comment
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.

Saved Queries