@elvisangelaccio was this one committed, since it mentions FIXED-IN: 1.2.2 in the Differential summary but I don't see the commit in the Differential log?

In D9806#203992, @elvisangelaccio wrote:

I'm not sure I'm following: all the 3 steps in the test plan work for me, without this patch.
Is there something else needed to trigger the bug?

In D9706#201266, @dvratil wrote:

While technically all your observations are correct, when dealing with data coming from a proprietary service where we cannot do any assumptions about their implementation, it's better to write the code defensively and not just assume that the way things happen to work now is set to stone. Our only guideline is the API documentation. Any other observations about the data I prefer to treat as a coincidence that happens to work for me and the few documents on my GDrive, but may break in the real world.

Implement @dvratil's recommended code changes per D9706#188708 and document the reasoning behind the extra safeguard as comments in the code.

Hey @elvisangelaccio, please accept my apologies for the delay - I needed some time to understand the code due to my sheer lack of experience, since I'd like to to grasp why a certain change is being recommended rather than blindly implementing it. After reading through the relevant chunk of code again I now understand and agree with @dvratil's recommended change, but I do have two additional questions.

In D9774#193850, @elvisangelaccio wrote:

@martijnschmidt What's the email you want to use for the commit authorship?

I don't have commit rights - this is my 2nd KDE patch ever, so please go ahead and push it to the repository. Thanks! :)

In D9706#188090, @dvratil wrote:

For documents created in Google Docs, GDrive API will list them as GDocs documents, which nobody else but GDocs can open. It, however, provides a list of mimetypes into which GDocs can convert the document for download. The code here is used so that we can show GDocs documents as .odt/.ods/.pdf/.... documents that users can click and open in their computer.

As such, the mappings here are used to map from the mimetypes in externalLinks to some usable mimetype. Since Google still documents the "broken" mimetype as used, we should keep it supported, alongside the correct one.

I've uploaded two Differentials for this task;

In T3443#123172, @dvratil wrote:

From the KGAPI perspective, looking at the V2->V3 API migration guide (https://developers.google.com/drive/v3/web/migration) it appears that it should not be too much work to add V3 API to KGAPI for KIO GDrive to use.

The migration document also mentions some changes in parent handling that might make it actually easier to deal with the parent changes.

Regarding the Trash, the change in V3 is that it's no longer an actual folder that can be referenced from the API but simply just a collection of all Files with the trashed parameter set to true. My understanding is that there is still Trash in V3, but it's up to the implementators to create it themselves and only show trashed files in it. You can list all trashed files via

GET https://www.googleapis.com/drive/v3/files?q=trashed%3Dtrue&key={YOUR_API_KEY}

So trashing items should only be a matter of updating the file's trashed property.

Ahh, I had completely missed that. So looking at the v3 API we should do something like the following to move the file to trash:

PATCH https://www.googleapis.com/drive/v3/files/fileId
{
  "trashed": true
}

In D9706#187375, @elvisangelaccio wrote:

In D9706#187374, @martijnschmidt wrote:

Hi Elvis, I ran a diff -u a/src/gdrivehelper.ccp b/src/gdrivehelper.cpp to create this output.

git diff from the kio-gdrive repo should be enough

Re-export the diff with "git diff" instead of "diff -u".

Hi Elvis, I ran a diff -u a/src/gdrivehelper.ccp b/src/gdrivehelper.cpp to create this output.

Looking at your comments in the code with regard to trash:

It looks like the whole trash feature is no longer made available in the Google Drive API v3: https://developers.google.com/drive/v3/reference/files