mguessan / davmail

DavMail POP/IMAP/SMTP/Caldav/Carddav/LDAP Exchange and Office 365 Gateway - Synced with main subversion repository at
http://davmail.sourceforge.net
GNU General Public License v2.0
582 stars 86 forks source link

Calendar events disappearing in Thunderbird #287

Closed maxanier closed 1 year ago

maxanier commented 1 year ago

I am having issues with a Exchange calendar added to Thunderbird via Davmail. I am not yet sure if it is a Thunderbird, a Davmail or a configuration issue.

Many calendar events keep appearing and disappearing upon manual/automatic calendar sync. When initially opening the calendar all events are present, but when a synchronization occurs some events are removed.

In the Thunderbird console a "REPLY method but calendar does not support scheduling" ("CalDavCalendar.jsm:952") is logged. I captured one event that triggers this error (and disappears from the calendar) from the Thunderbird debugger which is attempted to be added in addTargetCalendarItem:

BEGIN:VCALENDAR
METHOD:REPLY
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:STANDARD
DTSTART:16010101T030000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
COMMENT;LANGUAGE=de-DE:
UID:040000008200E00074C5B7101A82E00800000000902FA4B7966ED80100000000000000001\ 00000006D59B36125BD7F43B3BC8D81B24AF2E5
SUMMARY;LANGUAGE=de-DE:Akzeptiert: Title
DTSTART;TZID="Europe/Berlin":20220601T110000
DTEND;TZID="Europe/Berlin":20220601T120000
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20220525T093512Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:1
LOCATION;LANGUAGE=de-DE:BAR209
X-MICROSOFT-CDO-APPT-SEQUENCE:1
X-MICROSOFT-CDO-OWNERAPPTID:-1732814874
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
END:VEVENT
END:VCALENDAR

I do not fully understand how the synchonization works, but I assume the following: Initially the full calendar is downloaded from the davmail address. That file contains one VCALENDAR with METHOD:PUBLISH and all the events, which are then successfully added to the calendar. Then, during synchonization, events are synced individually (separate VCALENDAR) and the "invitation" events have a METHOD:REPLY which causes issues.

Thunderbird thinks that the calendar does not support scheduling. The davmail server reports the feature "calendar-auto-schedule" and Thunderbird successfully recognizes this and sets mHasAutoScheduling to true. Hence, mHaveScheduling is false. Appearently, Thunderbird does not expect events with METHOD:REPLY when auto scheduling is enabled.

I also tried enabling calendar.caldav.sched.enabled in the Thunderbird configuration, but it did not change anything.

Using DAVx5 on Android does work fine.

I don't really know what is at fault here, and where to continue looking.

maxanier commented 1 year ago

Ah, I think the update calendar item above does not come from davmail, but is extracted from the invitation email which is still present in the exchange box (PRODID:Microsoft Exchange Server 2010).

If I purge this Email from my inbox, the respective event does not disappear anymore.

My email account is currently setup to access the Exchange server directly. But I also tried accessing it via Davmail and I am still getting the same calendar updates with REPLY method

Do you have an idea how to stop this behavior?

mguessan commented 1 year ago

Thanks for your feedback, will need to investigate this further.

maxanier commented 1 year ago

Thank you. Let me know, if you need further information or if you have an idea where I could continue debugging.

fk0 commented 1 year ago

I have exactly the same issue and I'm very interested in fixing it. I can help with any type of debugging you need. My setup:

QuickJack commented 1 year ago

Same here. Thunderbird logs "REPLY method but calendar does not support scheduling" ("CalDavCalendar.jsm:952") and loops continuously. I guess it's the same issue that has been described at https://sourceforge.net/p/davmail/discussion/644057/thread/7eb9565d8a/.

maxanier commented 1 year ago

The linked issue sounds similar, but does not mention the "REPLY method.." line. Also, for me, not only reoccurring events but also single events are affected and keep disappearing. The common thing between these events is that they are all events that have an invitation email alongside.

mguessan commented 1 year ago

Ok may have found the root cause, Thunderbird merged Lightning extension (calendar) and dropped the old user agent. ... and DavMail has specific code for Lightning.

Thus I will first try to adjust user agent test and see how far we go.

mguessan commented 1 year ago

Please try latest trunk build available from github (appveyor builds)

QuickJack commented 1 year ago

I have tested the latest trunk build and the issue seems to be fixed now. Thank you for your work.

maxanier commented 1 year ago

Awesome, I will also try to test it soonish myself

maxanier commented 1 year ago

Didn't expect setting up a local davmail service would be so quick ^^

I can confirm that the latest trunk build fixes my issue. (Tested 6.1.0-trunk and 6.1.0-3423 windows-standalone, and only the new trunk version works)

Thank you very much! If possible, I would appreciate a versioned release, so my university can update its hosted service.

lhallsw commented 1 year ago

Trying to download https://ci.appveyor.com/api/projects/mguessan/davmail/artifacts/dist%2Fdavmail-6.1.0-trunk-setup64.exe I get:

404 Not Found

What am I missing?

esabol commented 1 year ago

@lhallsw : Your URL is incorrect. Try this: https://ci.appveyor.com/api/projects/mguessan/davmail/artifacts/dist/davmail-6.1.0-trunk-setup64.exe

lhallsw commented 1 year ago

@esabol: Sorry for the typo. Using https://ci.appveyor.com/api/projects/mguessan/davmail/artifacts/dist/davmail-6.1.0-trunk-setup64.exe instead, I instead get: 400 Bad Request

esabol commented 1 year ago

That URL works for me. "400 Bad Request" sometimes mean you have a corrupt cookie. Try quitting your web browser and re-opening it. Try it in a private or incognito window. Or try a different web browser entirely.

lhallsw commented 1 year ago

OK, maybe it's something "local" then, although I tried it on 2 different computers with different browsers, on different networks, in different geographic locations.

400 actually is the response I get from wget when trying to download the link directly. If I just click on the link in a browser, I see the following message:

{"message":"\"job\" parameter must be specified if build contains multiple jobs.\r\nParameter name: job"}

esabol commented 1 year ago

All I can say is that I've downloaded that URL 3 times, and it's worked every time.

maxanier commented 1 year ago

I am also having issues downloading the trunk builds.

The links from the README give me {"message":"Artifact not found or access denied."}

The link by esabol gives me {"message":"\"job\" parameter must be specified if build contains multiple jobs.\r\nParameter name: job"}

esabol commented 1 year ago

Yeah, I eventually saw that message myself. So I emailed support@appveyor.com and I was told you need to append ?job={job_name} to the ci.appveyor.com URL.

So the URL should be

https://ci.appveyor.com/api/projects/mguessan/davmail/artifacts/dist/davmail-6.1.0-trunk-setup64.exe?job=Environment%3A%20JAVA_HOME%3DC%3A%5CProgram%20Files%5CJava%5Cjdk1.8.0

according to the README.md, but that returns the message "Artifact not found or access denied." I'm guessing either the value in the job parameter is wrong or the artifact has expired and appveyor.com has deleted it?

lhallsw commented 1 year ago

Yes, I see the same thing with the new URL you posted above.

At least we know it's an AppVeyor issue.

For the moment, I've worked-around the issue by pulling the code and building it locally. With a couple of days of testing, it looks good to me.

Thanks very much for this. It has actually been a regular source of pain for me for some time so it's really great to have it fixed.