Please move the kio_gdrive.cpp refactoring to another commit, depending on this one.

Added more functions and refactored KIOGDrive.

Added test case, is the test sufficient?

Bonus point if you add a test case in urltest.cpp ;)

I see. Then I'd exclude #3 for the reason you mentioned. I'd be ok with either #1 or #2, with a slight preference for #2.

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

Team Drives can be show in a couple of ways

In D9806#230386, @martijnschmidt wrote:

@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?

@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?

The patch seems to fix the problem, great!
Code looks good besides the inline comment.

Ah right, so this is https://bugs.kde.org/show_bug.cgi?id=376735

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?

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.

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.

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.

@martijnschmidt Any update on this? I think @dvratil's suggestion is a safe choice, so I'd also vote for that.

Sorry, I wasn't very clear explaining myself above.

Nice job! I have one remark, but that's probably up to @elvisangelaccio to decide which is the best course of action.

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;

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.

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

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 application/x-vnd.oasis.opendocument.spreadsheet was used intentionally since that's what GDrive returns in the exportLinks for the Google Documents spreadsheets:

In D9706#187374, @martijnschmidt wrote:

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

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

Thanks for the patch, but I cannot apply it right now. How did you create the diff? Please see https://community.kde.org/Infrastructure/Phabricator#Posting_a_Patch

@martijnschmidt Wow, thanks for your analysis!

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

Oh OK, sorry. I'll remember that for the future.

@ngraham Frameworks is the group for the "Frameworks" product, but kio-gdrive is not part of it. Also, all repositories part of Frameworks already get Frameworks as subscriber, so apart from exceptional cases, adding Frameworks to a review should almost never be needed.

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

doesn't the existing google account for telepathy already request google drive access?

It seems this is fixed in 1.1.x, the auth dialog shows up only if I press F5 after deleting the last account.

Work in progress in kaccounts branch, works fine.

In D4613#86774, @poboiko wrote:

I've pushed it to master, see commit 6370278224b423615e9469ccd59cd7f43d5fe346.

Unfortunately, I haven't learned how to proper use phabricator yet, so closing this issue by hand.

I've pushed it to master, see commit 6370278224b423615e9469ccd59cd7f43d5fe346.

Thanks. Do you have commit access?

Replaced tabs for 4 spaces (kind of weird how they appeared: never used tabs for indentation... :S) and other comments

Thanks for the patch, tested and it works. By the way I submitted a patch (D4622) to fix the typo you spotted.

Indeed it's a bug in cmake: https://gitlab.kitware.com/cmake/cmake/issues/15419

Could be a Dolphin bug, possibly related to: https://bugs.kde.org/show_bug.cgi?id=370355

Turns out this is easy: we just need to install the following .desktop file in usr/share/remoteview/:

And kaccounts-mobile uses both KAccounts and libkgapi: https://github.com/KDE/kaccounts-mobile/blob/master/google/google-contacts-sync/google-contacts-plugin.cpp