1. 14 Jan, 2021 2 commits
    • flypig's avatar
      Merge branch 'jb52657' into 'master' · e646c75c
      flypig authored
      Ensure recurrenceId is parsed from the network reply correctly
      See merge request !82
    • flypig's avatar
      [buteo-sync-plugins-social] Pass recurrenceId to the network reply as a... · 6ad19520
      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.
  2. 06 Jan, 2021 1 commit
  3. 05 Jan, 2021 1 commit
  4. 20 Dec, 2020 1 commit
  5. 18 Dec, 2020 1 commit
  6. 03 Dec, 2020 2 commits
  7. 30 Nov, 2020 1 commit
    • flypig's avatar
      [buteo-sync-plugins-social] Keep track of additions for later modifications in... · d7ad8519
      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.
  8. 26 Nov, 2020 6 commits
    • flypig's avatar
      [buteo-sync-plugins-social] Set recurrence start time when converting from... · 92d6b826
      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's avatar
      [buteo-sync-plugins-social] Translate between mkcal and Google EXDATEs. Contributes to JB#51507 · 970beac8
      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's avatar
      [buteo-sync-plugins-social] Record sync time as time started, rather than time... · ff50cac4
      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's avatar
      [buteo-sync-plugins-social] Remove code for supporting multiple accountIds. Contributes to JB#51507 · e1f966eb
      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's avatar
      [buteo-sync-plugins-social] Use client timestamp for sync time. Contributes to JB#51507 · 58813eea
      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
    • flypig's avatar
      [buteo-sync-plugins-social] Allow sync to continue on delete event error. Contributes to JB#51507 · f9b5f8d7
      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.
  9. 25 Nov, 2020 4 commits
  10. 24 Nov, 2020 3 commits
  11. 16 Nov, 2020 1 commit
  12. 12 Nov, 2020 2 commits
  13. 04 Nov, 2020 2 commits
    • blam's avatar
      Merge branch 'jb51831-google-fullname' into 'master' · 356f1b4f
      blam authored
      [buteo-sync-plugins-social] Don't set Google gd:fullName as customLabel field. Fixes JB#51831
      See merge request !76
    • Bea Lam's avatar
      [buteo-sync-plugins-social] Don't set Google gd:fullName as customLabel field. Fixes JB#51831 · c1239f22
      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.
  14. 02 Nov, 2020 1 commit
  15. 30 Oct, 2020 1 commit
  16. 29 Oct, 2020 2 commits
  17. 26 Oct, 2020 1 commit
  18. 21 Oct, 2020 2 commits
    • blam's avatar
      Merge branch 'jb51541' into 'master' · 16ac4989
      blam authored
      [buteo-sync-plugins-social] Fix bugs in Google Contact sync. Contributes to JB#51541
      See merge request !71
    • Bea Lam's avatar
      [buteo-sync-plugins-social] Fix Google contact sync issues. JB#51541 · dbc7cbba
      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.
      - 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. 19 Oct, 2020 2 commits
  20. 12 Oct, 2020 2 commits
  21. 07 Oct, 2020 1 commit
  22. 06 Oct, 2020 1 commit