I guess with D28162: [calendar] Implement SyncToken for Calendar service and D28560: [resources] Add a unified Google Groupware Resource this is fixed now.

Thanks for the fix. Since this is a bugfix, please land this patch to the Applications/19.08 branch, then merge the branch to master.

Well spotted! Thanks

Regarding point 1, mea culpa 😬

Sounds like there might be a problem with exports or some symbol name duplication that leads to some weird behavior during LTO.

Fixed minor nitpicks

Just minor nitpicks. Fix those and you can commit the patch. Thanks!

Remove debug info from permissions example.

@dvratil I rechecked if Permission was complete and added missing attributes. Also added an example.

Added parameter default values to member initialization.

Thanks for the fix. Could you also modify the constructors so that the class members are initialized using the fooDefault constants as well, so that we really only have a single place in the entire file where the default value is defined?

That sounds like a better way of handling defaults, I'll keep it in mind when touching other Jobs.

Nice, thanks for the patch.

Added missing derived class access-specifier to PermissionDeleteJob.

@barchiesi This commit broke the kio-gdrive build (CanCreateTeamDrives no longer existing).

Nice trick! :)

• Silence Team Drive deprecation warnings for examples and tests.

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

It's fine to leave it in and ignore the warnings - I think there's some way to disable deprecation warnings internally, but I can't find it now.

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?

Looks good, thanks a lot!

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

• Added canCreateDrives attribute to About.

Renamed wrong attributes in Drives::Capabilities.

In D20843#468955, @dvratil wrote:

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

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

Changed (wrong) commit email address.

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

Please don't forget to bump kio-gdrive's KGAPI_MIN_VERSION to the new libkgapi's KGAPI_VERSION_STRING.

That worked, thanks :)

Just use --skip-dependencies - arc is confused becasue the commits from previous reviews landed with different commit hashes than arc expects.

I think this patch needs to be rebased, here's what I get when I try to apply it:

You should be able to apply the last missing patch on top of libkgapi master (I've merged all the previous ones just now)

Hmm, I can't apply this patch because arc complains about the missing patches on libkgapi.

Have all the changes from this draft been submitted? If so, can this be abandoned? :)

@elvisangelaccio can you review this patch, please? I'll be merging @barchiesi's LibKGAPI patches that affect the API, so I would merge this at the same time and bump the KIO GDrive dependency so everything keeps compiling.

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

Ah, my bad. In that case, @barchiesi , please bump PIM_VERSION in CMakeLists.txt` as part of this patch, so kio-gdrive can depend on a specific version with the fixed API.

Since we need to wait for LibKGAPI 19.08, I'd actually prefer to not use #ifdefs but just make kio-gdrive master depend on LibKGAPI master. There are no other features waiting to be released anyway.

@barchiesi can you update D20888 to add #ifdefs for kgapi version, please, so I can start merging this patchset? :-)

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.

I was planning to do a new kio-gdrive release once we can announce Team Drive as working feature.

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.

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.

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).

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.

Does this change require any changes to KIO GDrive?

Good work, thank you!

Thanks!

supportsTeamDrives documentation says "Use supportsAllDrives instead, for includeTeamDriveItems to use includeItemsFromAllDrives, so I think we don't have to set all four of them, only the "allDrives" versions, they all have the same effect. In this case 1:1 mapping with the REST API is not necessary, IMO

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.