CalDAV issue with Thunderbird Lightning

[nicorac]

My configuration:

• eGroupware 20181018 on Ubuntu Server 18.04 x64
• CalDAV client: Thunderbird 60.3.1 with bundled Lightning extension 6.2.3.1 on Windows 10 - 1709 - x64

Issue:
unconfirmed events (the ones I was invited to but not yet accepted/refused) correctly appear grayed with dotted border in Lightning calendar but they disappear after the 2nd calendar resyncs (by pressing Lightning resync button).

This is fully reproducible:

• open Thunderbird and the unconfirmed event is shown (grayed with dotted border)
• press Resync button and the event is still there
• press Resync again and the event disappears.

After it disappears, to make it appear again I need to restart Thunderbird.
This is annoying because if I set the calendar to update each 1min, then the event will disappear after 2 minutes…

I’m testing other groupware suites (namely SOGo) and they don’t have this issue.

I’ve set up a test environment to find the cause of this bad behavior:

• user source@example.org creates an event “AAA” and invites user destination@example.org
• user destination@example.org opens its Thunderbird and can see the AAA event as unconfirmed into his Lightning calendar
• after 2 resyncs the event disappears (it is still visible in eGroupware calendar web page)

This is Apache log after a successful refresh (the unconfirmed event still appears in Lightning calendar):

10.0.0.1 - destination@example.org [03/Dec/2018:15:15:45 +0100] "PROPFIND /egroupware/groupdav.php/destination%40example.org/calendar/ HTTP/1.1" 207 1225 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 Lightning/6.2.3.1"
10.0.0.1 - destination@example.org [03/Dec/2018:15:15:45 +0100] "PROPFIND /egroupware/groupdav.php/destination%40example.org/inbox/ HTTP/1.1" 207 1713 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 Lightning/6.2.3.1"
10.0.0.1 - destination@example.org [03/Dec/2018:15:15:45 +0100] "REPORT /egroupware/groupdav.php/destination%40example.org/inbox/ HTTP/1.1" 207 2298 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 Lightning/6.2.3.1"

This is Apache log after a bad resync (the unconfirmed event disappeared from Lightning calendar):

10.0.0.1 - destination@example.org [03/Dec/2018:15:15:49 +0100] "PROPFIND /egroupware/groupdav.php/destination%40example.org/calendar/ HTTP/1.1" 207 1068 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 Lightning/6.2.3.1"
10.0.0.1 - destination@example.org [03/Dec/2018:15:15:49 +0100] "PROPFIND /egroupware/groupdav.php/destination%40example.org/inbox/ HTTP/1.1" 207 1713 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 Lightning/6.2.3.1"
10.0.0.1 - destination@example.org [03/Dec/2018:15:15:49 +0100] "PROPFIND /egroupware/groupdav.php/destination%40example.org/calendar/ HTTP/1.1" 207 1068 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 Lightning/6.2.3.1"
10.0.0.1 - destination@example.org [03/Dec/2018:15:15:49 +0100] "PROPFIND /egroupware/groupdav.php/destination%40example.org/inbox/ HTTP/1.1" 207 1713 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 Lightning/6.2.3.1"

I’m attaching 3 eGroupware CalDAV log files: thunderbird start, first resync, second resync.

Feel free to ask for further details…

1-ok-thunderbird-start.txt (15.9 KB)
2-ok-thunderbird-first-resync.txt (7.0 KB)
3-ko-thunderbird-second-resync.txt (7.9 KB)

[nicorac]

Just updated to version 17.1.20181205, but it has the same behavior: unaccepted events disappear from calendar after 2nd resync…

[RalfBecker]

I once had a similar problem on a customer installation:

• Thunderbird has a problem with it’s cache when you do multiple resync
  (If you don’t believe me, trace the communication with the server and you will find when TB does not show the events, they have been send by the server.)
• Why do you resync anyway, probably because you don’t see new events, which is an other bug in TB, if the server does not support WebDAV Sync reports, as most modern servers do nowerdays
• EGroupware does WebDAV Sync report, if it is has not been switched of explictly, which it probably is on your server. The configuration ist under Admin >> Application >> Calendar >> Site configuration >> History Logging >> Prefent deleting of events: This must NOT be “No”! CalDAV Sync report requires history logging and therefore one of two “Yes, …” configurations
• changing the config in EGroupware alone does not help, as TB caches if a server supports Sync report, even if you delete the account in TB
• We found only two solutions:
  a) delete the whole TB profile directory or
  b) change the domain of the EGroupware server

Ralf

[nicorac]

Thanks for your reply.

Why do you resync anyway, probably because you don’t see new events…

I manually resync only to avoid waiting for (at least) 2 automatic resyncs and accelerate the bug to appear.
By default my clients are set to auto-sync each 5 mins, so the bug appears after 10/15 mins.

EGroupware does WebDAV Sync report, if it is has not been switched of explictly, which it probably is on your server.

You’re right, now I’ve set it as shown in the picture below:

but I still have the same bug…

a) delete the whole TB profile directory

I’ve started TB (60.3.1) with a new profile, bug persists …

[nicorac]

An update to my previous post:

I’ve received an update alert from Thunderbird to update from 60.3.1 to 60.3.2.
After updating it, the bundled Lightning extension was updated too (from 6.2.3.1 to 6.2.3.2).

I’ve installed it and… it works!
Repeatedly clicking the Sync button won’t make the unconfirmed events to disappear.

Will try to downgrade back to TB 60.3.1 to check if the bug reappears…

[nicorac]

Downgraded to 60.3.1 but the bug didn’t come back.
It now all works even with the original 60.3.1 version of TB.

It passed a couple of hours between EGW configuration change and TB upgrade (despite forum posts timestamps).
Could it be that some cache expired meanwhile?

Anyway I’m glad that I don’t need to rush updating all of my clients

Will update this thread if the bug gets back.
Thanks for your help.