Now, I started a precious discussion on the future of Funambol which actually was not my
intention ;)
Back to my problem:
I figured out there are tow tables: jdoe123 and jdoe123_quick . Two my point of view jdoe123
contains correct data, i.e. there is an entry CLASS:PRIVATE in the vcal blob. However, the
entries in jdoe123_quick differ from really private appointments in the sense that there are
three flags zero instead of one: c_classification, c_isopaque, and c_status. I guess one of
those flags is the one causing the trouble.
So my question: Is there a way to make SOGo recompute this jdoe123_quick table from the
entries in jdoe123?
Thanks,
Mirko
On 12/13/2011 09:25 AM, Mirko Stoffers wrote:
On 12/13/2011 08:39 AM, Christian Mack wrote:
Hello Mirko Stoffers
On 2011-12-13 14:26, Mirko Stoffers wrote:
Sorry for the horrible formatting of the last mail. Here again in
readable formatting:
Addendum: Seems like there is already a bug report related to this issue
open since months:
http://www.sogo.nu/bugs/bug_view_advanced_page.php?bug_id=1319
Does nobody care about that issue? oOo
It is not important, as SOGo 2 will have native Outlook synchronisation
via OpenChange. With this you don't need Funambol anymore.
In our opinion (University of Konstanz) fixing this is a waste of
development time.
Hm, yes, maybe you're right. But can you nevertheless tell me how to get my
database right?
I actually don't know what went wrong. There is an entry saying
"CLASS:PRIVATE\r" in the
vcal entry in the database. However, there must be another kind of private tag
anywhere else
that is not set up appropriately.
Thanks,
Mirko
PS ad "you don't need Funambol anymore": How will mobile devices be synched
with SOGo 2?
--
users@sogo.nu
https://inverse.ca/sogo/lists
