mirror of
https://github.com/aluxnimm/outlookcaldavsynchronizer.git
synced 2026-04-26 11:35:47 +03:00
[GH-ISSUE #157] Duplicate events when using SOGo as backend #154
Labels
No labels
1.0
1.0
1.0
2.0
Feature
Feature request
Google
Google Calendar
async
attachement
auto-migrated
auto-migrated
auto-migrated
bug
critical
enhancement
help wanted
implemented
pull-request
solved
solved
sourceforge
sourceforge
sourceforge
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/outlookcaldavsynchronizer#154
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @kheiken on GitHub (Aug 22, 2016).
Original GitHub issue: https://github.com/aluxnimm/outlookcaldavsynchronizer/issues/157
We are using the Synchronizer in combination with SOGo and we recently noticed the following problem:
When you are invited to an event by another user that is located on the same server, the Synchronizer messes up the events:
Upon invitation, SOGo writes the event to the invitees calendar and sends an invitation mail to the invitee.
Caldav Synchronizer does what it is supposed to do: It grabs the event from the server and puts it into the invitee's Outlook calendar. It ignores the original organizer and sets the invitee as the new organizer.
Now if the invitee accepts the invitation, a notification is sent to the invitee instead of the original organizer.
Now when Outlook receives the email, it creates another event with a different UID in my local calendar. Then there are two events in my calendar(s) for the same event.
When activating the option to remove duplicates, it seems non-deterministic which event gets deleted - sometimes the event from SOGo gets deleted, which means the user can no longer see the event in the browser or on other devices - and changes to that event do not cleanly propagate to the invitee.
Are you aware of these problems in relation to SOGo or am I simply doing something wrong?
Thank you very much for your work with the Synchronizer. For ages there hasn't been a working solution for the Outlook/CalDAV dilemma. Now there finally is; so thanks again.
@aluxnimm commented on GitHub (Aug 22, 2016):
Yes there are issues with mail invites from Outlook, thats why we implemented the option to delete duplicates. But we should check the behaviour which of those duplicates gets deleted, You say it is non-deterministic, what do you suggest? Always delete the one generated from Outlook?
Regarding the organizer, I don't understand exactly why the organizer is ignored? What Outlook version are you using? The organizer should be correctly synced from SOGo to Outlook. Can you provide an example ics file?
Another woraround is to set SCHEDULE-AGENT=CLIENT to avoid that SOGo schedules the meeting and only work with email invites from Outlook or whatever client sends them.
@kheiken commented on GitHub (Aug 22, 2016):
My colleague just invited me to an event; I created a gist for the ics generated by SOGo.
In Outlook, the event is displayed as if I was the organizer:
When I right-click on the event in the synchronized calendar, an invitation reply is sent to myself, instead of the original organizer (as seen in the ics file).
@aluxnimm commented on GitHub (Aug 22, 2016):
Ok I guess the problem is that the organizer has the email adress as CN value and no real name and can't be resolved in Outlook, will check If we can fix that and set the email only as organizer in such cases.
@aluxnimm commented on GitHub (Aug 22, 2016):
ok fixed in
3ce57e972dAny thoughts on the duplicate delete handling?
@kheiken commented on GitHub (Aug 22, 2016):
Awesome, thanks!
I think it would be ideal if only the event in the local Outlook profile is deleted, if there is an event with the same Timing (beginning and end) and Subject in a synchronized CalDAV calendar available.
That way the event is always correctly mapped to SOGo and changes to the event should be replicated correctly.
To be honest, I am not a regular Outlook user. My understanding of the Outlook profiles etc. is very limited. So maybe what I am suggesting is utterly wrong...
@aluxnimm commented on GitHub (Aug 30, 2016):
can you test 2.5.0 please ? it should map the organizer correctly.
you can also change the outlook option that mail invites don't automatically add tentative appointments, see
https://www.msoutlook.info/question/do-not-automatically-accept-meeting-as-tentative
@kheiken commented on GitHub (Aug 30, 2016):
Indeed it does, thank you.
We will test how that option changes the behavior.
I'll get back to you as soon as possible.
@prachtkerl commented on GitHub (Sep 5, 2016):
Hello,
feedback from Uni Hannover
The first Bug is fixed, now in new events from CalDAV the correct organizer is shown, but only if
we have "Map Organizer and Attendees".
We test with Two-Way-Synchonization with "Automatic". We do not want Outlook-User to have two different calendar-folder, so the folder in the synchronization-profiles is the default-folder of Outlook.
Now we create events in SOGo and look what is happening in Outlook.
Scenario 1: Outlook's first contact with the event is via email. The CalDAV synchronization did not yet contain this new event.
Here everything looks pretty good if he simply "accepts" the invitation from the mail view.
UID in the reply is the one from created entry, with SOGo the reply can be processed and the
attendee will be marked as "accepted". In Outlook, there is only one event shown, no second
one occurs after synchronization. But in the mail-replys, in the ICal-Part, the ORGANIZER-Field is missing. May be that's why my Lightning is complaining that the event can not be processed.
Scenario 2: The user was inactive for a while and does not react instantly to the email. Now if the CalDAV synchronization runs, the event is imported directly to the calendar.
The eventis directly marked as accepted, manually accepting the reply creates a new event without an
ORGANIZER and a new UID, so that new event cannot be mapped to the original one.
Now reading the e-mail, we create a second event at the same time, this one most of the time with original UID. But there are a some events that might have own UID, nevertheless the Mail-Reply of these events has the original UID. Processing that reply as the organizer creates a third calendar entry.
Sorry, we can not exactly say how to reproduce that.
And somehow, maybe triggered by a sync, not by users, and under circumstances we cannot exactly reproduce either, there will be an e-mail created from Outlook where the user declines an invitation. ORGANIZER is OK, UID is the original.
@aluxnimm commented on GitHub (Sep 5, 2016):
Thank you for your feedback!
Of course, because if map organizer and attendees is not set, that attributes are ignored, but this setting is the default anyway.
We are aware of certain race conditions for new invitations and you are right,it makes a difference if the mail arrives first or if the event is synced first.
Regarding scenario 1:
Do you have "Synchronize items immediately after change" activated? It can cause problems at the moment and we want to exclude those invites from immediate sync to the server in the next release.
The mail reply is missing the organizer? Didn't notice that yet, but we can't do much, since Outlook itself is sending those accept mails.
ad scenario 2:
If the event was not accepted in SOGo it shouldn't be auto accepted after sync, but it wasn't shown as tentative. This is also fixed for the next release. What we also plan ist to discard the mail invite when syncing the event directly, similar what Outlook does when importing the event to the calendar. This will avoid a second event when the user accepts the mail.
When accepting invites from Outlook for existing events, Outlook creates a new event and replaces the old one, our sync detects a new and a deleted event and Sogo sends a decline and an accept mail, we try to fix this also for the next release and avoid the cancellation and recreation.
So for now it is recommended to avoid "Synchronize items immediately after change" and wait for the next release for better invitation support.
@aluxnimm commented on GitHub (Sep 28, 2016):
Please test version 2.6.1, it should avoid most problems with invites and declined meetings.
@aluxnimm commented on GitHub (Oct 9, 2016):
Version 2.7.0. fixes the mapping of UID to Outlook GlobalAppointmentID and should avoid problems with your scenario 2. This works in Outlook 2013+ only.