2

I'm facing an issue with an application I'm developing using Google Drive.

I have a Google group with some users inside, and I share a collection with this group. When I try to find this collection using Google Drive API (files().list()), as one of the users of this group, the collection shows up properly.

However, if I add another user to the group (either using API or Google CPanel), and try to find the collection using Google Drive API as this user, the collection doesn't show up, as if the user is not able to see it even though he is in a group allowed to see the collection.

If I manually open once the collection through my browser, then the collection is showing through Drive API.

Is this a normal behaviour ? In my use case I cannot expect from the users to open in their browser each and every collection shared with them in order for the application to work.

Any insight?

Burcu Dogan
  • 9,153
  • 4
  • 34
  • 34
brian
  • 802
  • 4
  • 18
  • This is not expected, could you query files.list with `sharedWithMe` to see if it's being listed or not? – Burcu Dogan Jun 05 '13 at 07:44
  • @burcu-dogan It seems the sharedWithMe option displays files shared with the user directly only, in my case, it's through a group, and I've confirmed that it's not showing with this option, whatever user of the group. Without the option, I've tried again and same conclusion: the collection is listed in the API's answer only after I opened once the folder in my browser, otherwise it's not showing. Note that I'm trying to list files querying on their title, maybe it's related: q="title ='foldername'" – brian Jun 05 '13 at 08:42
  • I think it's expected to see them listed after user opens the file. It's a confirmation. Am I right? – peter Jun 05 '13 at 20:58
  • In that case: 1/ What's the point of having APIs if we need to rely on user interactions 2/ When we share the folder for the first time with the group, there is no need for users to open the file, no confirmation, the files are listed instantly with the API. The issue only occurs for users added to the group afterwards. The behaviour seems inconsistent to me. – brian Jun 07 '13 at 16:47
  • @brian, this sounds like a bug. I'm checking if this was by intention. – Burcu Dogan Jun 09 '13 at 15:47
  • @BurcuDogan Any news on that subject ? The only trick I've found for now is to unshare and reshare the files to the group each time a new member is added to the group. How ever it induces a lot of requests. And another strange behaviour, if the user removes the file from the Shared With Me section in his Drive, then even though the file is still shared with him and he still has access to it from the link, it doesn't show anymore in the API. – brian Jul 25 '13 at 09:43

1 Answers1

5

I opened a Google Support case about this and apparently this behavior is "expected". Here are some excerpts from my exchange with "Angel" from Google Enterprise Support (typos corrected and emphasis mine):

After reviewing the stackoverflow question, we need to clarify to you that the behavior shown is expected. When adding a user to a group, this group must be added again for any files that it has been shared with.

and

All information previously provided is from internal documentation for Drive UI; however the functionality is the same for SDK, therefore, group must be deleted and added back to the list of users that have access to files/folders after adding a new member.

So, there you have it. Not sure if @Burcu will ever come back and confirm.

<EDIT> It gets worse. According to this Google document, groups with more than 200 members will never see files shared with them, even if you delete and add the group back. </EDIT>

Useless post-answer rant follows:

This behavior, even if it is "expected" by Google, does not seem to be properly documented, and it is neither expected nor usable by clients of the service. How are we supposed to know when a user has been added to a group that has items shared with it? Are we supposed to constantly monitor group memberships as well as maintain a list of all things shared with the group and then *re*share them with the group when the membership changes, just to get consistent behavior? It makes me wonder why Google doesn't already do this on the back end; it can't be that expensive to register a list of callbacks with a group that are triggered upon membership changes. And the requirement that we actually unshare is even more bizarre, since it necessitates a short period of time during which nobody in the group can access the resource.

jcalz
  • 264,269
  • 27
  • 359
  • 360
  • I feel your pain. I'm not sure "groups with more than 200 members will never see files shared with them" is quite the whole story. They can see the files, but not under "Shared With Me". – pinoyyid Nov 13 '13 at 16:02
  • Thanks. I meant they wouldn't see them in files.list. – jcalz Nov 13 '13 at 20:14
  • I'd like to add that with files.get() the file shows up properly, so it seems that this behaviour is valid for files.list() only. – brian Nov 18 '13 at 14:35
  • Right; when you call `files.get()` you are accessing a particular file by id and if it is shared with you then you can access it. One would think that `files.list()` would be the full list of files a user can access, but it is not. It seems to be a manually maintained list, although you [don't necessarily have the tools to manage it](http://stackoverflow.com/questions/19958047/). It's very frustrating trying to actually build something on top of this platform. Calling `files.list()` is fast but not reliable. Calling `files.get()` repeatedly is reliable but very slow. – jcalz Nov 18 '13 at 14:54
  • There's something strange, I've been performing some tests for an hour and today even with files.list() I can see the files properly after adding a user to a group, without having to share/unshare. I tried this several times and the file always shows up directly after the member has been added to the group, however the file is not showing in the Shared With Me section. Either I made 10 times the same mistake during my tests or something has changed. Do you observe the same thing ? – brian Nov 18 '13 at 15:13
  • 1
    After more tests, the file shows up in files.list() with the query 'folderId' in parents, but with a query on title for example, no results. Real consistency issue there. – brian Nov 18 '13 at 15:38
  • Interesting. My guess is that when you use the "'folderId' in parents' query it is actually ignoring the manually maintained list (whose existence I conjectured above), and instead is enumerating the children of the folderId, much as in the `Children.list` call. – jcalz Nov 18 '13 at 19:03