Support for recurrent events from external providers, integration with Nextcloud and other improvements

[edgarlemke]

We've been using SnappyMail together with Nextcloud, as well as deployed to our clients, and received a complain about a problem. When:

1. a recurrent event is created in an external provider (e.g. Google Calendar, Outlook) and the invite is sent to an e-mail account we manage;
2. the event is accepted in SnappyMail and added to the Nextcloud Calendar;
3. the recurrent event has a single instance of the event changed (e.g. a recurrent event for 5 days at 9am - 10am but the 3rd day event is edited to be at 10am - 11am) and the change is sent to the e-mail account again. In Google Calendar specifically it's asked whether the change applies only to this single event, to the next ones and to all, in this case it's only the single event;
4. the changed event is added to the calendar again in SnappyMail.

What happens then is that instead of having only the single instance changed and the other instances unchanged, all the other instances are deleted and only the single instance changed is kept in the calendar.

After diagnosing the cause, it was found that what happens is that Google Calendar sends the ICS file containing only the data for the changed instance, instead of sending all the data related to the single recurrent event plus the exceptions. So it's not really SnappyMail's fault but I suggest the fix could become a feature. Also after discussing it with our product manager, related changes were suggested to improve usability, which anyway could be merged to SnappyMail's code base.

So I ended up coding stuff that:

• makes the recurrent events changes work properly. The Nextcloud backend is checked for events with the same UID and if proper, the ICS content is merged and sent to the back end via a PUT request.
• shows a popup with a success message when an event in the case above is accepted and added successfully to the back end database.
• shows a popup with a failure message when an event can't be properly merged or fails to be added.
• shows a popup with a success message when an event (any event) is accepted and added successfully.
• shows a popup with a failure message when an event is accepted and it fails to be added.
• checks the back end to see if the event has already been added. If it's the case, it substitutes the "Add to calendar" label to an "Invite already added" label and disallows clicking for adding the event again.
• checks the back end to see if a newer event with the same UID has already been added. If it's the case, it substitutes the "Add to calendar" label to an "Old invitation" label and disallows clicking for adding the event again.
• checks the back end to see if the event of the currently open message is an update to an already added, older event with the same UID. If it's the case, it substitutes the "Add to calendar" label to an "Update on my calendar" label.

The diff patch has been attached to the issue.
patch.txt

Waiting for a feedback.

Thank you!

[the-djmaze]

I've implemented your patch.

It is missing language strings for:

• OLD_INVITATION
• UPDATE_ON_MY_CALENDAR
• LAST_INVITATION"
• EVENT_UPDATE_FAILURE_TITLE
• EVENT_UPDATE_FAILURE_BODY
• EVENT_UPDATED_TITLE
• EVENT_UPDATED_BODY

See https://github.com/the-djmaze/snappymail/blob/master/plugins/nextcloud/langs/en.json

Can you add them?

[edgarlemke]

Sure, I will. I will also add the strings for pt-BR, since we're located in Brazil.
Also, I inform that after some validations, we found some problems in the original patch. There are some bad interactions related to the VEVENT properties and the substitution of the "SAVE_ICS" label for the other labels. So I advise not to release it as it is.
We're waiting for a response from our client and when we confirm it's working correctly for us, I'll inform it.

[Luncheon3462]

Sure, I will. I will also add the strings for pt-BR, since we're located in Brazil. Also, I inform that after some validations, we found some problems in the original patch. There are some bad interactions related to the VEVENT properties and the substitution of the "SAVE_ICS" label for the other labels. So I advise not to release it as it is. We're waiting for a response from our client and when we confirm it's working correctly for us, I'll inform it.

@edgarlemke any update from your client?