- 14 Jan, 2021 2 commits
-
-
flypig authored
[buteo-sync-plugins-social] Pass recurrenceId to the network reply as a QVariant. Contributes to JB#52657 Various items of data are attached to the QNetworkReply for use when the reply returns. The recurrenceId was being parsed in as Qt::ISODate format, but written out as Qt::TextDate format. As a result, the recurrenceId was always empty, and the parent recurring event was being amended by the upsync response rather than the exception. This change attaches the recurrenceId property to the QNetworkReply object as a QVariant, so that it's restored correctly.
- 06 Jan, 2021 1 commit
-
- 05 Jan, 2021 1 commit
-
-
Bea Lam authored
The KDateTime-specific formatting should no longer be used. Dates should be parsed in either ISO format or the yyyyMMddThhmmssZ format.
-
- 20 Dec, 2020 1 commit
-
- 18 Dec, 2020 1 commit
-
-
Bea Lam authored
-
- 03 Dec, 2020 2 commits
-
-
Chris Adams authored
-
- 30 Nov, 2020 1 commit
-
-
flypig authored
[buteo-sync-plugins-social] Keep track of additions for later modifications in the same sync. Contributes to JB#51507 If an event is added during a sync, its details must be kept track of in case further modifications occur to the event (e.g. exceptions to or deletions from the recurrence rule) later in the same sync. The additions were already being carefully ordered to ensure they're inserted first, but there were some details not added to the maps for finding the parent event later. This change inserts the event details in these maps as the sync progresses so that later modifications can be applied successfully.
-
- 26 Nov, 2020 6 commits
-
-
flypig authored
[buteo-sync-plugins-social] Set recurrence start time when converting from json. Contributes to JB#51507 The recurrence rules store the event start time separately from the event itself. If set incorrectly (or not at all) the rules end up being badly formed, and other actions (e.g. dissociating event exceptions) could fail. Events extracted from the database have recurrence start times automatically set to the event start time, but this wasn't happening during json deserialisation. This change adds it in. The issue was triggered when an update for the main event was received from google (resulting in a json deserialisation), followed in the same sync by a new recurrence exception for the same event. In this case, the dissociation for the recurrence was failing due to the lack of start time in the recurrence rule. If the changes were received in separate syncs the problem didn't arise, since the main event had been "washed" through the database.
-
flypig authored
Whenever an event from a recurring series is given an exception event (e.g. a single event in the series is edited), a new child event is created for the exception. mkcal also adds an EXDATE to the recurrence rule for the parent to remove the original entry that was edited. In contrast, Google doesn't add an EXDATE, but just automatically performs the removal. This causes problems for syncing. This change adds the extra EXDATEs to the recurrence rules of downsynced events as needed by mkcal, and removes them from the recurrence rules of upsynced events.
-
flypig authored
[buteo-sync-plugins-social] Record sync time as time started, rather than time ended. Contributes to JB#51507 This change records the time at the start of the sync and uses this as the previous sync time. This ensures that any events modified after the start of the sync will be uploaded in the next sync. Deleted events (both local and remote, where the change is already on the server, are also now purged from the database after a successful sync to avoid any attempt to upload the deletion to the server on the next sync (which would cause an error).
-
flypig authored
These changes don't affect functionality, the aim is only to improve code clarity. Various parts of the code (notably in the finalCleanup() method) were already assuming that the adapter would service only a single account during its lifetime. This change removes the additional code needed to support multiple accountIds, which was going unused.
-
flypig authored
The deleted and modified times of events are stored using the client timestamp. If the timestamp returned by the server is used to determine the upload delta, this can result in the wrong entries being uploaded. In particular it was resulting in events deleted on the server being uploaded as new deletions to the server, causing an error. This change sets the notebook last sync time using the current client timestamp, to ensure only entries changed after the latest sync are uploaded to the server. In the reverse direction the server uses a sync token to determine which events to sync, so the change doesn't affect which events are downloaded.
-
flypig authored
If an error is triggered due to an event being deleted that's already been deleted from the server, this change allows the sync to continue. This ensures the account doesn't have to be recreated to fix the issue on the client.
-
- 25 Nov, 2020 4 commits
-
-
Chris Adams authored
-
Chris Adams authored
-
Chris Adams authored
If a previous sync cycle (using a previous version of the sync plugin) had caused Google Contacts to be stored to the database with remote avatar image URLs, then we need to correct that on subsequent sync cycles by detecting that this has occurred for a contact, and treating the contact as remotely modified.
-
- 24 Nov, 2020 3 commits
-
-
Chris Adams authored
-
Chris Adams authored
If some avatars were not downloaded due to transient error, request throttle, etc, then we should ensure that we download those during subsequent sync cycles. Also, ensure that we only trigger avatar downloads once all other sync requests are complete, to avoid throttling of sync requests.
-
- 16 Nov, 2020 1 commit
-
- 12 Nov, 2020 2 commits
-
-
Chris Adams authored
The avatars must be transformed prior to when they are stored in the local database, so don't delay that operation until the next event loop. In order to avoid the (potential) QNAM crash, delay the call to AbstractImageDownloader::queue() instead.
- 04 Nov, 2020 2 commits
-
-
Bea Lam authored
The customLabel field is used as the default display label in the QtContacts backend, and since the customLabel for a Google contact is only updated during a sync operation, the customLabel (and hence the contact's display label) was not updated when the contact name changed outside of a sync operation. It's not necessary to set this as the customLabel field in any case, because we need to always send the latest version of the formatted name (according to any local name changes for the contact) in order to avoid spurious modification notifications from the server.
- 02 Nov, 2020 1 commit
-
- 30 Oct, 2020 1 commit
-
-
pvuorela authored
-
- 29 Oct, 2020 2 commits
-
-
Bea Lam authored
-
- 26 Oct, 2020 1 commit
-
-
Bea Lam authored
Starting avatar downloads immediately after the last request has finished causes a crash in QtNetwork.
-
- 21 Oct, 2020 2 commits
-
-
Bea Lam authored
When upsyncing contacts, the server will reply with an updated etag for each contact in postFinishedHandler(). Save the etags to their contacts before calling localChangesStoredRemotely(), which will save the updated contacts to the database. Also save the avatars at this point instead of in finalize(), as calling QContactManager::saveContacts() will flag the contacts as modified and cause spurious modification detections on the next upsync. Also: - Ensure the correct detail is looked up for the etag data - Don't remove contacts from the localAdded/Modified lists in batchRemoteChanges(), because these lists are then passed onto localChangesStoredRemotely() for saving - Save the last sync time in finalize() so that it is not saved if the sync failed.
- 19 Oct, 2020 2 commits
-
-
Bea Lam authored
-
Bea Lam authored
Encode and decode the gd:fullName entry in the atom feed. The server always sends a fullName composed from the first name, last name, prefix etc. so encoding this in the request will avoid a spurious modification from the server on the next sync after it reassembles the fullName on the server side.
-
- 12 Oct, 2020 2 commits
-
-
chriadam authored
We no longer hardcode the name of the default My Contacts collection, so when searching for it we cannot look for the hardcoded name. Instead, mark the collection with a special piece of metadata. Also fix a bug in etag detection. Finally, ensure we ignore detail access constraints when updating detail data during sync.
-
chriadam authored
-
- 07 Oct, 2020 1 commit
-
- 06 Oct, 2020 1 commit
-