Moved supportsAllDrives from FileAbstractUploadJob to FileAbstractDataJob so both FileCopyJob and FileCreateJob benefit.

As per Google's new naming, Team Drives have been renamed to Shared Drives.

Looking at accounts-sso/signon-plugin-oauth2, it seems they switch to refreshing if a previous token request returned a refresh_token in the response (which should be our case).

Changed commit email address.

Fixed the const issues.

@elvisangelaccio We have a refresh token available that could be used but I couldn't find any information regarding refreshing an account through KAccounts. Do you know if such functionality is available? If not, would you perhaps know who I can reach out to?

• Silence Team Drive deprecation warnings for examples and tests.

@dvratil this seems like a possible solution, what do you think?

In D21838#480527, @barchiesi wrote:

• Deprecate Teamdrive fetch/create/modify/delete jobs.
  
  I added KGAPIDRIVE_DEPRECATED_EXPORT to the create/delete/modify/fetch jobs and afterwards all tests and the teamdrive example show warnings. Is that correct? Or should I delete tests/examples?

Fixing previous edit mistakes (not sure what happened, still trying to understand arc).

• Added canCreateDrives attribute to About.

Renamed wrong attributes in Drives::Capabilities.

• Deprecate Teamdrive fetch/create/modify/delete jobs.

In this revision I would like to also include deprecation notices/warnings on the Teamdrive resource, as it is officially deprecated by Google. What is the correct way to do this?

In D20843#468955, @dvratil wrote:

Sorry, I must have overlooked this one :( You should be able to commit it for yourself now (arc land).

Changed (wrong) commit email address.

Fixed

Yes I did

All changes have been covered by other differentials, this can be abandoned.

Updated after changes to D20064

You are correct, fixed those issues

I bumped PIM_VERSION, but I'm not sure how versioning works in this project so I only increased the PATCH number.

LibKGAPI 19.04 has full support for the Teamdrives REST API but unfortunately that isn't sufficient for completely manipulating them in KIO GDrive. The KIO GDrive patch for Team Drives that I'm working on requires this revision for querying if the user can create Team Drives and it requires D20789 for uploading files and finding parents. I'll probably find more stuff that needs to be added to LibKGAPI.
Therefore KIO GDrive won't be able to support Team Drives until LibKGAPI 19.08. As soon as I have most of the functionality ready, I will submit a revision so you can start looking at it.

Add commit to revision.

Add commit to revision.

Maybe this time

Got it.

I'm still new to phabricator, I hope this is what you meant.

Updated after revision D20789 change.

Updated after revision D20789 change.

Updated after revision D20789 change.

Added the supportsAllDrives query param to other Jobs that can use it.

Added more functions and refactored KIOGDrive.

In D20886#458007, @dvratil wrote:

Since this changes the API, we must also bump the version in CMakeLists.txt. KIO GDrive will then have to have an #ifdef on LibKGAPI version to use either the old or the new approach, based on against what version of LibKGAPI it is compiled. This LibKGAPI API will not be publicly available until August (KDE Applications 19.08 release).

Another option is to have KIO GDrive master depend on the master of LibKGAPI and not doing any KIO GDrive release from master until LibKGAPI 19.08 is released (but I doubt @elvisangelaccio would be too happy about that :-) )

I guess we should let @elvisangelaccio decide, I believe the first approach is better because it allows building a newer KIO GDrive against older versions of LibKGAPI.

Added Teamdrive field mappings.

Yes this change affects all LibKGAPI users that used the FileFetchJob::setFields() function. A patch for KIO Gdrive fixes the incompatibility, although I'm not sure how to specify that it should be blocked until the new LibKGAPI release.

It seems like Google updated the v2 and v3 Drive references. The Teamdrive part of the API that I recently added is now considered deprecated and Drives should be used instead. Sintactically they are very similar, if not same apart from the added features.

Changed DeleteJob and ContactModifyJob to demonstrate prettyPrint overriding.

So I ditched Job::authorizedRequest() and now apply auth headers and standard params directly in Job::Private::_k_dispatchTimeout(). Basically I realized that perhaps some kind of jobs don't need the prettyPrint param set to false (no output or the cost is greater than the gain? delete methods maybe?) and in these cases I want to be able to remove the query param in the dispatchRequest implementation (eg. DeleteJob::dispatchRequest).
Does the above seem reasonable?
I also fixed up a little FileLogger so it produces a cleaner output.

Ok so I updated most test urls to reflect the prettyPrint change. I'm not sure what is left out but I will soon find out.
I also refactored File and FileFetchJob so the setFields is centralized. This will require that dependent projects rewrite their FileFetchJob::setFields() invocations, not sure how much of a negative impact that is...

Added test case, is the test sufficient?

I noticed most jobs set the Authorization header on their own so perhaps a standard request builder is needed. I added Job::authorizedRequest with encapsulates this and also adds standard query parameters.

No the API only exposes the list, clients choose how to present them to users.

In T10521#179011, @dvratil wrote:

@barchiesi how much is still missing in the KGAPI code for the Teamdrive support?

Had some typos in copyright notices.

When D19836 gets approved I believe this task is complete, @dvratil correct me if I'm wrong.