Note created in the app does not show up in Kolab's web UI about kolabnotes-android

[konradrenner]

is it reproduceable?

[lhitc]

Yes, reproducible.
I noticed the following main differences in the XML:

Note by Roundcube: note version="3.0dev1"
Note by app: note version="3.0"

Note by Roundcube: in description's head section: meta name="qrichtext" content="1" /
Note by app: in description's head section: meta name="kolabnotes-richtext" content="1" /

obviously also the prodid differs:
Roundcube-libkolab-1.1 Libkolabxml-1.1
kolabnotes-android

I have not checked any IMAP related flags.

The "mail body" of Roundcube-created notes has no line breaks (all text in a single line) when viewing from Thunderbird while there are 4 lines in notes created by the app. Maybe a problem with special characters?

[konradrenner]

maybe special characters, can you send me the kolab.xml file? do you have the problem with any note you create with the app?

[lhitc]

This happens also when editing an existing note. Steps:

1. create a note in Roundcube
2. note shows up in Roundcube and (after sync) in the app
3. edit the note with the app
4. after sync the note is invisible in Roundcube, but visible via IMAP (i.e. Thunderbird)

[lhitc]

I played around a bit with the HeaderTools Lite Addon for Thunderbird which allows viewing and complete editing of stored IMAP objects.

When copying the content of a visible note into the defective one and only changing the subject back to the defective note's subject, the defective note shows up in Roundcube.
Since there are a lot of differences in the header, multipart encoding and things like line breaks in the stored Kolab XML, I didn't manage to track the issue down to a certain header field or whatever, but a systematic walkthrough should give a result.
At least we can say it's apparently not an issue of some obscure IMAP flags.

[konradrenner]

In the subject, there must be the uid of the note. Is the UID of a defect note, in the subject and in the XML file the same or different?

[lhitc]

Mail subject and uid in the XML are identical on a defective note.
During playing around, when an edited defective note was visible in Roundcube, that note consisted of the full content and header data of a correct note, but it's subject was the one from the defective note.
So in the case when it showed up, the UIDs actually were not identifical between subject and XML.

[konradrenner]

please test the fourth preview, i have made some changes in the sync algorithmus. I cannot reproduce this problem :-(

[lhitc]

No change for me with the fourth preview.
New notes from the app are still visible in Thunderbird, but not in Roundcube

[lhitc]

Btw. when I look into Roundcube's Settings -> Folders it say 15 messages in the notes folder. 15 messages is also what I see from Thunderbird. Still I only see 9 notes...

[konradrenner]

This is so strange. I had not the time yet to set up a kolab server on my own. I use my KolabNow account for testing. Maybe notes are handled a little bit different in the Kolab version of KolabNow and on Kolab 3.3. Can you please ask a Kolab mailinglist, if there is a difference?

[lhitc]

I'm just digging deep into Kolab's PHP code to track down where the 15 notes become 9.
If I get lost, I'll follow your advice ;-)

[konradrenner]

Thank you very much, I must say, I have no idea what the problem could be... If you need information, how my sync library sets information, just contact me or look in the kolabnotes-java source ;-)

[lhitc]

I kind of found it.
There's a cache table for each Kolab object within the Roundcube MySQL database.
The table "kolab_cache_note" holds only the 9 messages I see in Roundcube...

Now got to find out why the cache is not updated when IMAP storage is changed externally.
This is either a major bug in the Kolab main distribution or a configuration issue.

[lhitc]

I filed an issue agains the Roundcubemail Kolab plugins in Kolab's Bugzilla:
https://issues.kolab.org/show_bug.cgi?id=5109

The problem even persists when I turn off Kolab caching in Roundcube's configuration.
Since I don't want to fiddle around with caching code on my production server, I'll leave that to the Kolab devs.
That is, if there is no option the app can force Kolab including Roundcube into a cache sync. But I don't see one atm.

[lhitc]

@konradrenner Can you provide some info into the Kolab Bugzilla issue? That issue has been changed to NEEDINFO state.
Though you can't reproduce the issue, it might be a good idea to communicate directly with the guys over there, like in "syncing the data needs syncing the developers" ;-)

[konradrenner]

@lhitc I don't have an account for the Kolab Bugzilla. Maybe you can ask in the issue, if there is a difference between KolabNow and your Kolab version in the notes handling? Can you turn on debug logs on your kolab server and then sync the app with the server, maybe there is some output?

[greve]

Works for me on Kolab Now, btw.

[lhitc]

@greve Yes, the issue is definitely related to the kolab_notes plugin for Roundcube. Unfortunately, Roundcube is the default frontend of the distribution ...

[greve]

I know. But what I am saying is that when I use my Kolab Now account, and create a note on my Android, then sync against the server, I see the note in the Kolab Notes Web Application on Kolab Now.

[konradrenner]

@lhitc have you added the question if there is an difference between Kolab Now Web UI and "standard Roundcube"?

[konradrenner]

@lhitc I think this problem is handled in the issue you created, is it ok for you to close the issue here on GitHub?

[lhitc]

@konradrenner If you mean the Kolab bugtracker issue https://issues.kolab.org/show_bug.cgi?id=5109 : we're not getting further over there.
They seem to expect some debug information but I have no idea how to provide it.

Basically it's Roundcube's cache that is not updating, but I don't know whether there is any API call to force that which might be added to the app (or whether there is a simple configuration issue in my installation).
I would be glad if you could talk to them directly...

[konradrenner]

I have added a comment in the Kolab bugzilla issue. I think this issue should be handled there.

[lhitc]

The Kolab devs have now identified it as a bug in libkolab, so definitely no issue here.