starred/outlookcaldavsynchronizer

Fork 0

mirror of https://github.com/aluxnimm/outlookcaldavsynchronizer.git synced 2026-04-26 03:25:48 +03:00

[GH-ISSUE #125] Tentatively accepted meetings #588

New issue

Closed

opened 2026-03-01 17:40:07 +03:00 by kerem · 7 comments

kerem commented

2026-03-01 17:40:07 +03:00

Owner

Originally created by @marcelbrueckner on GitHub (Apr 7, 2016).
Original GitHub issue: https://github.com/aluxnimm/outlookcaldavsynchronizer/issues/125

Hello,

I'm synchronizing an Exchange calendar one-way with a Baïkal v0.2.7 CalDAV server.

Since version 2.0.0 (or one of the other last versions) my meeting's "invitation answer status" isn't synchronized and so new meetings appear as tentatively accepted (although I've accepted them on my Exchange calendar).

As you can see in my screenshot I'm using Mac OS X Calendar as CalDAV client.
The meeting on Monday appears as accepted but the meeting on Tuesday does not.
For both meetings I'm not the organizer. The meeting on Tuesday was updated by the organizer some time after a CalDAVSynchronizer update and all other meetings since then (see the meeting at Thursday 3PM) are tentatively accepted.

I don't want to accept the meeting invitation a second time on my Mac. They should have the same status as my Exchange calendar items. Are there any new configuration options I can use to restore the old behaviour?

Regards
Marcel

Originally created by @marcelbrueckner on GitHub (Apr 7, 2016). Original GitHub issue: https://github.com/aluxnimm/outlookcaldavsynchronizer/issues/125 Hello, I'm synchronizing an Exchange calendar one-way with a [Baïkal](https://github.com/fruux/Baikal) v0.2.7 CalDAV server. Since version 2.0.0 (or one of the other last versions) my meeting's "invitation answer status" isn't synchronized and so new meetings appear as tentatively accepted (although I've accepted them on my Exchange calendar). As you can see in my screenshot I'm using Mac OS X Calendar as CalDAV client. The meeting on Monday appears as accepted but the meeting on Tuesday does not. For both meetings I'm not the organizer. The meeting on Tuesday was updated by the organizer some time after a CalDAVSynchronizer update and all other meetings since then (see the meeting at Thursday 3PM) are tentatively accepted. ![calendar](https://cloud.githubusercontent.com/assets/3597890/14367573/05aeb340-fd19-11e5-8567-d15bbbf04484.jpg) I don't want to accept the meeting invitation a second time on my Mac. They should have the same status as my Exchange calendar items. Are there any new configuration options I can use to restore the old behaviour? Regards Marcel

kerem closed this issue

2026-03-01 17:40:08 +03:00

kerem commented

2026-03-01 17:40:08 +03:00

Author

Owner

@aluxnimm commented on GitHub (Apr 7, 2016):

Can you test 2.0.1, we fixed a regression in checking own identity for exchange accounts which was introduced in 2.0.0.

@aluxnimm commented on GitHub (Apr 7, 2016): Can you test 2.0.1, we fixed a regression in checking own identity for exchange accounts which was introduced in 2.0.0.

kerem commented

2026-03-01 17:40:08 +03:00

Author

Owner

@marcelbrueckner commented on GitHub (Apr 8, 2016):

I've updated to 2.0.1 and noticed the following:

"old" meeting items won't be updated with the current status
new meeting invitations will be synchronized as "tentatively accepted" (as I've enabled the sync after change) and after I accept an invitation in Outlook a second item is created on my CalDAV server with the status "accepted" -> I now have 2 items for 1 meeting

@marcelbrueckner commented on GitHub (Apr 8, 2016): I've updated to 2.0.1 and noticed the following: - "old" meeting items won't be updated with the current status - new meeting invitations will be synchronized as "tentatively accepted" (as I've enabled the sync after change) and after I accept an invitation in Outlook a second item is created on my CalDAV server with the status "accepted" -> I now have 2 items for 1 meeting

kerem commented

2026-03-01 17:40:08 +03:00

Author

Owner

@aluxnimm commented on GitHub (Apr 8, 2016):

Yes old meetings won't be changed unless you clear the sync cache, delete everything on the server and do a full sync Outlook->Server.

What happens if you disable sync changes immediately?
I guess the problem is that the invitation is synced immediately and when you accept it, Outlook creates a new Appointment with a new id and our sync logic can't detect that it is the same as the previous tentative item.

Does the email adress of the outlook profile match the email adress of the caldav server and are the attendees correct in both server items and the only difference that one of them is tentative?

@aluxnimm commented on GitHub (Apr 8, 2016): Yes old meetings won't be changed unless you clear the sync cache, delete everything on the server and do a full sync Outlook->Server. What happens if you disable sync changes immediately? I guess the problem is that the invitation is synced immediately and when you accept it, Outlook creates a new Appointment with a new id and our sync logic can't detect that it is the same as the previous tentative item. Does the email adress of the outlook profile match the email adress of the caldav server and are the attendees correct in both server items and the only difference that one of them is tentative?

kerem commented

2026-03-01 17:40:08 +03:00

Author

Owner

@aluxnimm commented on GitHub (Apr 8, 2016):

I tried to reproduce this behaviour. In may case with sync changes immediately I also got 2 items on the server but with the next (manual or timed) sync run the first one(tentative) gets correctly deleted again, since it is not present in Outlook. What sync mode are you using Outlook->Server(Replicate) ?

@aluxnimm commented on GitHub (Apr 8, 2016): I tried to reproduce this behaviour. In may case with sync changes immediately I also got 2 items on the server but with the next (manual or timed) sync run the first one(tentative) gets correctly deleted again, since it is not present in Outlook. What sync mode are you using Outlook->Server(Replicate) ?

kerem commented

2026-03-01 17:40:09 +03:00

Author

Owner

@marcelbrueckner commented on GitHub (Apr 8, 2016):

Yes, I'm using Outlook -> Server (Replicate) synchronization mode.

And you are right. Looking at my calendar on Mac OS X the first one got deleted.
If I change a meeting item in Outlook which is tentatively accepted on my CalDAV server but accepted on Exchange, the acceptance status gets properly synced on the next run.
I'm ok with that as I'm not having so many meeting items with that "problem".

The e-mail addresses don't match on these two servers. The attendees are correct in both calendars.

Nevertheless, maybe you want to consider an additional option to fully sync all calendar items once a day or so (regardless of the item's "changed" status) :)

@marcelbrueckner commented on GitHub (Apr 8, 2016): Yes, I'm using Outlook -> Server (Replicate) synchronization mode. And you are right. Looking at my calendar on Mac OS X the first one got deleted. If I change a meeting item in Outlook which is tentatively accepted on my CalDAV server but accepted on Exchange, the acceptance status gets properly synced on the next run. I'm ok with that as I'm not having so many meeting items with that "problem". The e-mail addresses don't match on these two servers. The attendees are correct in both calendars. Nevertheless, maybe you want to consider an additional option to fully sync all calendar items once a day or so (regardless of the item's "changed" status) :)

kerem commented

2026-03-01 17:40:09 +03:00

Author

Owner

@aluxnimm commented on GitHub (Apr 8, 2016):

I will further investigate if we can detect the duplicate invite. Another possibility would be an option to exclude tentative items from sync changes immediately.

@aluxnimm commented on GitHub (Apr 8, 2016): I will further investigate if we can detect the duplicate invite. Another possibility would be an option to exclude tentative items from sync changes immediately.

kerem commented

2026-03-01 17:40:09 +03:00

Author

Owner

@aluxnimm commented on GitHub (Oct 9, 2016):

should be fixed in 2.7.0.

@aluxnimm commented on GitHub (Oct 9, 2016): should be fixed in 2.7.0.