Ask / Submit

Revision history [back]

click to hide/show revision 1
initial version

posted 2018-11-16 15:55:33 +0300

This is not a solution yet, but I think I've identified the issue thanks to @FloR707 responsiveness and analysis of the logs. I've created a MER bug to follow the solving of this issue.

Sadly, this fix is not trivial and requires in my opinion to be well thought. I'll discuss with@chris.adams about the various options at hand. I'll update this answer with the evolution of the process.

This is not a solution yet, but I think I've identified the issue thanks to @FloR707 responsiveness and analysis of the logs. I've created a MER bug to follow the solving of this issue.

Sadly, this fix is not trivial and requires in my opinion to be well thought. I'll discuss with@chris.adams with @chris.adams about the various options at hand. I'll update this answer with the evolution of the process.

Edit 2018/11/19: I've added a test in the test suite of the CalDAV connector. It is demonstrating the problem raised by @FloR707. This test is mimicking the down-sync of a recurring event with an exception, showing that on next delta calculation, the event is reported as modified. Now, I need to find a way to solve it properly.

This is not a solution yet, but I think I've identified the issue thanks to @FloR707 responsiveness and analysis of the logs. I've created a MER bug to follow the solving of this issue.

Sadly, this fix is not trivial and requires in my opinion to be well thought. I'll discuss with @chris.adams about the various options at hand. I'll update this answer with the evolution of the process.

Edit 2018/11/20: I've updated the merge request with a fix proposition. Let's wait for Chris Adams to have time to give a look and give a feedback. For the braves, I've compiled a package for Buteo CalDAV code on MER OBS. You can try it with pkcon install-local buteo-sync-plugin-caldav-0.1.36*.rpm and revert to official Jolla version with pkcon install buteo-sync-plugin-caldav. I'm afraid the fix is not backard compatible with already synced events. Need to trash the account and recreate it. If it's working, there should be no more spurious modified events and later sync to read-only calendar should not fail.

Edit 2018/11/19: I've added a test in the test suite of the CalDAV connector. It is demonstrating the problem raised by @FloR707. This test is mimicking the down-sync of a recurring event with an exception, showing that on next delta calculation, the event is reported as modified. Now, I need to find a way to solve it properly.

This is not a solution yet, but I think I've identified the issue thanks to @FloR707 responsiveness and analysis of the logs. I've created a MER bug to follow the solving of this issue.

Sadly, this fix is not trivial and requires in my opinion to be well thought. I'll discuss with @chris.adams about the various options at hand. I'll update this answer with the evolution of the process.

Edit 2018/11/21: Chris reviewed the fix and proposed some improvements that I've done this morning. Besides, I was not clear in my previous message: don't trash your account _unless_ the synchronisation is always failing because the calendar on the server is read-only. For server calendars with write access, the fix should have no effect beside not up-syncing once a recurring event just after down-sync.

Edit 2018/11/20: I've updated the merge request with a fix proposition. Let's wait for Chris Adams to have time to give a look and give a feedback. For the braves, I've compiled a package for Buteo CalDAV code on MER OBS. You can try it with pkcon install-local buteo-sync-plugin-caldav-0.1.36*.rpm and revert to official Jolla version with pkcon install buteo-sync-plugin-caldav. I'm afraid the fix is not backard compatible with already synced events. Need to trash the account and recreate it. If it's working, there should be no more spurious modified events and later sync to read-only calendar should not fail.

Edit 2018/11/19: I've added a test in the test suite of the CalDAV connector. It is demonstrating the problem raised by @FloR707. This test is mimicking the down-sync of a recurring event with an exception, showing that on next delta calculation, the event is reported as modified. Now, I need to find a way to solve it properly.

This is not a solution yet, but I think I've identified the issue thanks to @FloR707 responsiveness and analysis of the logs. I've created a MER bug to follow the solving of this issue.

Sadly, this fix is not trivial and requires in my opinion to be well thought. I'll discuss with @chris.adams about the various options at hand. I'll update this answer with the evolution of the process.

Edit 2018/11/26: Thanks to Chris for the review and comments, the patch has been updated and accepted upstream this morning. Fix should arrive officialy in a later version of SailfishOS.

Edit 2018/11/21: Chris reviewed the fix and proposed some improvements that I've done this morning. Besides, I was not clear in my previous message: don't trash your account _unless_ the synchronisation is always failing because the calendar on the server is read-only. For server calendars with write access, the fix should have no effect beside not up-syncing once a recurring event just after down-sync.

Edit 2018/11/20: I've updated the merge request with a fix proposition. Let's wait for Chris Adams to have time to give a look and give a feedback. For the braves, I've compiled a package for Buteo CalDAV code on MER OBS. You can try it with pkcon install-local buteo-sync-plugin-caldav-0.1.36*.rpm and revert to official Jolla version with pkcon install buteo-sync-plugin-caldav. I'm afraid the fix is not backard compatible with already synced events. Need to trash the account and recreate it. If it's working, there should be no more spurious modified events and later sync to read-only calendar should not fail.

Edit 2018/11/19: I've added a test in the test suite of the CalDAV connector. It is demonstrating the problem raised by @FloR707. This test is mimicking the down-sync of a recurring event with an exception, showing that on next delta calculation, the event is reported as modified. Now, I need to find a way to solve it properly.

This is not a solution yet, but I think I've identified the issue thanks to @FloR707 responsiveness and analysis of the logs. I've created a MER bug to follow the solving of this issue.

Sadly, this fix is not trivial and requires in my opinion to be well thought. I'll discuss with @chris.adams about the various options at hand. I'll update this answer with the evolution of the process.