GitLab

The -Wno-deprecated-declarations flag doesn't work with MSVC, so
let's not try to set it on Windows.

StandardParams::PrettyPrint is being accessed externally and needs
to have public visbility.

Summary:
This patch is similar to {D28178}. Although `uid` is populated, and we can
freely dispatch both contact and photo modify requests in parallel, the
following race condition still sometimes happens:

 1) Contact modify request dispatched
 2) Contact photo modify request dispatched
 3) Photo reply arrives

At this point, `d->lastContact` is not yet populated, and we call
`processNextContact()`, which repeats steps 1 and 2 for the very same contact.
Which could happen again and again, if photo reply arrives first again.

Instead, I suggest to fire photo modify request only after we receive reply
for contact modify request, ensuring everything happens in the following order:

 1) Contact modify request dispatched
 2) Contact modify reply received
 3) Contact photo modify request dispatched
 4) Contact photo reply received

Test Plan:
 1) Modify a contact via KAddressBook
 2) Check logs
 3) (without patch) Bunch of modify requests somtimes gets fired
 4) (with patch) Only one modify request gets fired

Reviewers: dvratil

Reviewed By: dvratil

Subscribers: kde-pim

Tags: #kde_pim

Differential Revision: https://phabricator.kde.org/D28181

Summary:
When we run `ContactCreateJob`, the UID of a contact is not yet known.
We can only add a photo only after we receive a reply from main create job.

Also, since we also don't want the following race condition to trigger:
 1) Contact1 create request
 2) Contact1 reply, Photo1 change request, Contact2 create request
 3) Contact2 reply, Photo2 change request
 4) Photo1 reply (here both `currentContact` and `lastContact` is Contact2)
 5) Photo2 reply
we only go for next contact after the previous has been fully procesed:
 1) Contact1 create request
 2) Contact1 reply, Photo1 change request
 3) Photo1 reply, Contact2 create request
 4) Contact2 reply, Photo2 change request
 5) Photo2 reply

Test Plan:
Without patch:
 1) Create a contact with photo inside KAddressBook
 2) Check Web UI: no photo is set, sometimes bunch of contacts get created (?)
With patch:
 2) Observe a single contact with a proper photo being set

Reviewers: dvratil

Reviewed By: dvratil

Subscribers: kde-pim

Tags: #kde_pim

Differential Revision: https://phabricator.kde.org/D28178

Summary:
This is an implementation of a `syncToken` Google API feature (see {T8376}, and
https://developers.google.com/calendar/v3/reference/events/list) which is a
native way to perform incremental updates.

When `EventFetchJob` is created, we can provide it with a token by calling
`job->setSyncToken(token)`, which will be used as a parameter for fetching.
Note: some of the parameters are incompatible with `syncToken` (`timeMin`,
`timeMax`, `updatedMin`, see API link above), so if token is provided, those
parameters get ignored.

When the job is finished, the next sync token can be obtained via
`job->syncToken()`. This token then can be used for the next `EventFetchJob`.

Test Plan:
1. Create an `EventFetchJob` with no `syncToken`
2. When job is finished, fetch its `syncToken`
3. Create a new job, using previous `syncToken`
4. Only incremental changes are obtained

Reviewers: dvratil

Subscribers: kde-pim

Tags: #kde_pim

Differential Revision: https://phabricator.kde.org/D28162

Summary:
According to Google Calendar API (https://developers.google.com/calendar/v3/reference/events/move),
the proper url is `https://www.googleapis.com/calendar/v3/calendars/calendarId/events/eventId/move`

Test Plan:
1) Move event between calendars in KOrganizer
2) The change gets propagated to Google Calendar Web UI

Reviewers: dvratil

Reviewed By: dvratil

Subscribers: kde-pim

Tags: #kde_pim

Differential Revision: https://phabricator.kde.org/D28160

Summary: The change was reverted in qtnetwork.

Reviewers: mlaurent

Reviewed By: mlaurent

Subscribers: kde-pim

Tags: #kde_pim

Differential Revision: https://phabricator.kde.org/D28010

GIT_SILENT: Prepare 5.14.0 beta1. Update ecm as 5.67.0 is broken see 417396. 5.68 will be release in 2 days. But dependancy freeze is tomorrow.

Summary: Events were never being deleted as a result

Reviewers: dvratil

Reviewed By: dvratil

Subscribers: kde-pim

Tags: #kde_pim

Differential Revision: https://phabricator.kde.org/D27374

Summary:
According to [[ https://developers.google.com/calendar/v3/errors ]], the server can return a 410 error if the syncToken or updatedMin is too old.
There is already code to preemptively request a full sync, but specifically for the "Contacts" calendar the server-side limit is much lower than usual, generating these errors and preventing sync.

Test Plan:
  - Set last sync for "Contacts" calendar to five days ago.
  - Observe 410 error being returned.
  - Verify that a full sync is performed.

Reviewers: mlaurent, dvratil

Reviewed By: dvratil

Subscribers: lbeltrame, kde-pim

Tags: #kde_pim

Differential Revision: https://phabricator.kde.org/D27062