1. 05 Feb, 2021 1 commit
  2. 01 Feb, 2021 6 commits
    • flypig's avatar
      [buteo-sync-plugins-social] Purge ophan 'ghost' events. Contributes to JB#52608 · e5802286
      flypig authored
      During ghost event cleanup, any orphans that don't belong to any
      notebook are deleted. This also purges them so they no longer exist in
      the database after the sync.
    • flypig's avatar
      [buteo-sync-plugins-social] Ensure clean sync is applied in full. Contributes to JB#52608 · 5716a644
      flypig authored
      The google sync plugin can be tricked into performing a "partial clean
      sync" if both the syncToken and syncTime are invalid. This state can
      occur, for example, if the account has never managed to complete a fully
      successful sync.
      The result of this state is that all events are considered as insertions
      (as opposed to modifications), while at the same time the notebook isn't
      recreated from scratch. As a result, duplicate entries are added to the
      calendar on each sync.
      This change fixes this by identifying the case where the syncToken and
      syncTime are both invalid and ensuring the clean sync semantics are
      applied throughout the sync (so everything is an insertion, but the
      notebook is also recreated and so starts empty).
    • flypig's avatar
      [buteo-sync-plugins-social] Clamp min sync time to within a year. Contributes to JB#52608 · be42096a
      flypig authored
      For accounts that have never experienced a successful sync, the last
      sync time may return 0 with an invalid sync token. This will cause the
      next sync to be clean, but with the requested minimum time set to 0
      (i.e. "1970-01-01T00:00:00Z").
      In practice, it never makes sense to sync back this far, so now the
      start time is bounded below by a year prior to the current time.
    • flypig's avatar
      [buteo-sync-plugins-social] Flag individual event sync errors. Contributes to JB#52608 · f84fbba1
      flypig authored
      Uses the volatile custom properties of KCalendarCore to store sync
      errors for individual events, matching the approach used by the CalDav
    • flypig's avatar
      [buteo-sync-plugins-social] Add dummy parent if Google sends an exception... · ed57e167
      flypig authored
      [buteo-sync-plugins-social] Add dummy parent if Google sends an exception without one. Contributes to JB#52608
      If Google sends an exception event during a sync for which the parent
      recurring event doesn't exist, this would previously cause the entire
      sync to fail. This change instead creates a dummy parent event, matching
      the exception, which the exeption is then dissociated from.
      This allows the sync to succeed and the event to appear. This also
      matches the behaviour of the caldav sync plugin.
    • flypig's avatar
      [buteo-sync-plugins-social] Differentiate between 403 errors. Contributes to JB#52608 · d9789771
      flypig authored
      If Google returns a 403 error it can mean modifying a non-authored
      shared event, but it can also mean a usage limit has been reached. The
      first is ignorable for the full sync, whereas the second should block
      the full sync. They therefore need to be distinguished and handled
      Delete events that return 404 errors are also handled differently. These
      are ignored rather than causing the sync to fail.
  3. 29 Jan, 2021 4 commits
  4. 28 Jan, 2021 1 commit
  5. 27 Jan, 2021 3 commits
  6. 25 Jan, 2021 1 commit
  7. 22 Jan, 2021 1 commit
    • flypig's avatar
      [buteo-sync-plugins-social] Sequence exception insertions after their parents.... · a09bb070
      flypig authored
      [buteo-sync-plugins-social] Sequence exception insertions after their parents. Contributes to JB#52657
      For Google calender synchronisation, if an exception to a recurring
      event is upsynced as an insertion to the remote calendar at the same
      time as its parent recurring event, the two have to be sequenced
      carefully. The upsync of the parent has to complete fully before the
      child can be uploaded, otherwise Google won't find the parent and
      returns an error.
      This change adds a sequencing step that allows the relevant insertion
      upsyncs to be sequenced in this way.
  8. 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.
  9. 06 Jan, 2021 1 commit
  10. 05 Jan, 2021 1 commit
  11. 20 Dec, 2020 1 commit
  12. 18 Dec, 2020 1 commit
  13. 03 Dec, 2020 2 commits
  14. 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.
  15. 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.
  16. 25 Nov, 2020 4 commits
  17. 24 Nov, 2020 3 commits
  18. 16 Nov, 2020 1 commit