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 |
Maybe you can open another bug report or send a mail to kolab-dev.
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.
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.
Maybe you can open another bug report or send a mail to kolab-dev.
Cheers,
Gunnar
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
State ⇒ Resolved
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?
Queue ⇒ Kolab
State ⇒ Assigned
New Attachment: framework-Kolab-preserve-multiple-categories.patch
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
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?
Would it make sense if the Kolab driver sees an unknown (=new)
category to automatically add it?
n categories. Still have to think about a way to properly fix that,
if possible.
multiple categories - also known as tags? ;) - but I don't think it's
productive to try and do that for the 3.2 releases.
I'll have to check if I can -reliable- preserve the multiple fields somehow.
Thomas
State ⇒ Feedback
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?
impossible for a shared calendar / addressbook?
is accessing the data.
n categories. Still have to think about a way to properly fix that,
if possible.
multiple categories - also known as tags? ;) - but I don't think it's
productive to try and do that for the 3.2 releases.
Patch ⇒ No
State ⇒ Unconfirmed
Milestone ⇒
Queue ⇒ Horde Base
Summary ⇒ Category handling
Type ⇒ Bug
Priority ⇒ 1. Low
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