6.0.0-beta1
7/8/25

[#6621] Category handling
Summary Category handling
Queue Kolab
Type Bug
State Resolved
Priority 1. Low
Owners wrobel (at) horde (dot) org
Requester thomas.jarosch (at) intra2net (dot) com
Created 04/18/2008 (6290 days ago)
Due
Updated 04/24/2008 (6284 days ago)
Assigned 04/21/2008 (6287 days ago)
Resolved 04/24/2008 (6284 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
04/24/2008 07:29:57 PM thomas (dot) jarosch (at) intra2net (dot) com Comment #8 Reply to this comment
Is that a Horde bug? I had some utf-8 problems in XML myself lately.
Maybe you can open another bug report or send a mail to kolab-dev.
I think it's valid XML if you encode non-ascii characters as &xFC; for an ΓΌ.


04/24/2008 07:23:49 PM Gunnar Wrobel Comment #7 Reply to this comment

[Show Quoted Text - 16 lines]
Yes, it makes sense if you know your user base and can judge what they 
are doing. I just think that for the general case having one Kolab 
client correcting data from another client might not be the best idea.
btw: Speaking of broken data, I'm in contact with Niko Berger who
develops the Thunderbird Kolab plugin, looks like he fixed parsing
umlauts generated from Horde which are XML-entities instead of utf-8
:-) Will test it soon.
Is that a Horde bug? I had some utf-8 problems in XML myself lately. 
Maybe you can open another bug report or send a mail to kolab-dev.



Cheers,



Gunnar
Thomas
04/24/2008 06:41:39 PM thomas (dot) jarosch (at) intra2net (dot) com Comment #6 Reply to this comment
Hello Gunnar,

[Show Quoted Text - 9 lines]
Ok, that change is fine with me. I added the code to convert (old) 
broken data once the Horde client sees it. This would be useful if you 
restore old data from backups etc. Maybe I'll just leave it in my 
local copy, have to think about it a bit.



btw: Speaking of broken data, I'm in contact with Niko Berger who 
develops the Thunderbird Kolab plugin, looks like he fixed parsing 
umlauts generated from Horde which are XML-entities instead of utf-8 
:-) Will test it soon.



Thomas


04/24/2008 05:06:08 PM Gunnar Wrobel Comment #5
State ⇒ Resolved
Reply to this comment
In CVS, thanks.



The only thing I changed: I removed the "broken client" support. 
Rewriting the semicolon unconditionally to a comma seemed a little bit 
too limited to me. If it is really desired to support the broken 
notation we could probably do this depending on the product ID in the 
XML text.



Even if we would support the broken client notation I wonder if it 
makes much sense to rewrite the category entry within Horde then. Once 
the user connects with the broken client it would not understand the 
new category information, right?
04/24/2008 04:40:54 PM Gunnar Wrobel Assigned to Gunnar Wrobel
 
04/21/2008 06:01:32 PM Chuck Hagenbuch Version ⇒
Queue ⇒ Kolab
State ⇒ Assigned
 
04/21/2008 03:43:17 PM thomas (dot) jarosch (at) intra2net (dot) com Comment #4
New Attachment: framework-Kolab-preserve-multiple-categories.patch Download
Reply to this comment
Right now the string category name is stored, not an array index.
Ok, looks like a bug in the Kolab implementation. I'll look into it.
That turned out to be a "bug" at my local installation:

I forgot to upgrade attributes.php :-)



Attached is a patch to preserve multiple Kolab categories

if the category of an object does not change.

Please requeue to "Kolab".



Thomas


04/21/2008 10:05:42 AM thomas (dot) jarosch (at) intra2net (dot) com Comment #3 Reply to this comment
As far as I understood the internal data format of
Prefs/CategoryManager.php,
all clients save the (array) id of a category in their data
structures, regardless if you use a Kolab or SQL backend. Is that
correct?
Right now the string category name is stored, not an array index.
Ok, looks like a bug in the Kolab implementation. I'll look into it.



Would it make sense if the Kolab driver sees an unknown (=new)

category to automatically add it?
Also Horde allows only one category f.e. for a contact. Kolab allows
n categories. Still have to think about a way to properly fix that,
if possible.
Yeah, would be great to upgrade all Horde groupware apps to allow
multiple categories - also known as tags? ;) - but I don't think it's
productive to try and do that for the 3.2 releases.
Yeah, let's stabilize the release and then add more features :-)

I'll have to check if I can -reliable- preserve the multiple fields somehow.



Thomas


04/18/2008 06:05:46 PM Chuck Hagenbuch Comment #2
State ⇒ Feedback
Reply to this comment
As far as I understood the internal data format of Prefs/CategoryManager.php,
all clients save the (array) id of a category in their data
structures, regardless if you use a Kolab or SQL backend. Is that
correct?
Right now the string category name is stored, not an array index.
Wouldn't that make sharing the same set of categories between users
impossible for a shared calendar / addressbook?
It's done to make it clear what the category is, no matter what client 
is accessing the data.
Also Horde allows only one category f.e. for a contact. Kolab allows
n categories. Still have to think about a way to properly fix that, 
if possible.
Yeah, would be great to upgrade all Horde groupware apps to allow 
multiple categories - also known as tags? ;) - but I don't think it's 
productive to try and do that for the 3.2 releases.
04/18/2008 10:05:47 AM thomas (dot) jarosch (at) intra2net (dot) com Comment #1
Patch ⇒ No
State ⇒ Unconfirmed
Milestone ⇒
Queue ⇒ Horde Base
Summary ⇒ Category handling
Type ⇒ Bug
Priority ⇒ 1. Low
Reply to this comment
Hello together,



I'm currently testing different Kolab clients playing together with Horde.

As far as I understood the internal data format of Prefs/CategoryManager.php,

all clients save the (array) id of a category in their data 
structures, regardless if you use a Kolab or SQL backend. Is that 
correct?



Wouldn't that make sharing the same set of categories between users impossible

for a shared calendar / addressbook?



Also Horde allows only one category f.e. for a contact. Kolab allows n 
categories.

Still have to think about a way to properly fix that, if possible.



Thomas


Saved Queries