My question concerns Google Drive.
I would like to know how to maintain the same tree structure for all my users accross the organization when I share it. While keeping advanced and customizable ACL permissions for folders and sub-folders.
I am the admin of my Google Business Apps and my Drive folder tree is very well organized and structured. I want some users of my organization to be added to a folder "A" so they can access a sub-folder "A.1", but not the other sub-folders "A.2" and "A.3".
Right now it is pretty messy and hectic if I want to save my tree structure. Indeed, if I want to save my tree structures in my users' Drive, I have to give them access to the main folder "A" so they will be able to access sub-folder "A.1". However, if I do it, my users will be automatically able to access the other sub-folders 1.2. and 1.3. (because the person has access to the main folder "A"). Therefore, I have to manually restrict the access to the sub-folder "A.1" only. That's a pain.
When I give to my users access to the folder "A.1" only, the folder is shared individually and my users' Drive tree structure is no more organized. After sharing 20 folders, my users' Drive becomes pretty messy, while mine remains completely clean (since I created the tree structure and I have all the permissions).
Does anyone know how to efficiently share an identically Drive tree structure among the whole organization, without compromizing on the ACL?
Thanks,
B.
PS: The only post related to this problem is here but it doesn't answer my question: Google Drive - Change owner on folder, sub-folders and content, while saving tree structure
Regrettably, Google Team drive does not currently allow assigning permissions to team drive sub-folders or sharing symlinks across team folders. :(
As a result, our organization ended up creating dozens of team folders each based on role access. This approach solved several problems but created others and makes it hard to share content between roles.
Ideally... GOOGLE should update Team drive to allow permissions to be managed at the drive as well as subfolder level. Until they do the only way to share content within a team drive across roles is one file at a time.
Related
I'm looking to switch all domain-shared files from "Shared with Domain" to "Shared with group". I'm trying to identify whether a permission on a GDrive file (not from Shared Drive) is inherited or not. However Drive V3 API does not appear to expose permissions/permissionDetails attribute in same way as Shared Drives. Is there an efficient way to get the "inherited" status of a permissions? Trying to avoid having to walk the folder hierarchy.
Background on use case: We have decided that shared to domain is overly broad as the company grows. We have many consultants and contractors who should not see everything in the firm. We want to switch from Shared to domain to Shared with groups to better manage least privilege. We are aware that we cannot change UI at this time.
Answer:
There's no direct way to get the inherited status of file permissions in Drive API.
Explanation:
permissionDetails is only available to shared drive items, and neither Permissions nor Files include any additional fields regarding inheritance.
Therefore, I don't think you can use inheritance to filter out the files to update.
Feature request:
There's a feature request in Issue Tracker related to this:
Sharing permission inheritance details not mention in API
You could consider starring it in order to keep track of it and to help prioritizing it, but since it hasn't had much activity, I'd strongly suggest you to file a new one using this template.
Related:
Permission details are not returned in Google Drive API V3
Google drive api v3 permission details
We would like access to a client’s folder within their Google Drive and all files under that folder. This can either be a folder we create from the app or a folder the client picks.
The first approach I tried was to create the folder from the app.
The problem is that I am only able to list the folder itself, but NONE of the content. https://developers.google.com/drive/api/v3/folder
The second approach was to use the Google Picker API. There the
client can choose which folder(s) to give us access to. However we
can only get access to the folder, and none of the children
folders/files. https://developers.google.com/picker/docs
This seemed like an easy and straightforward use case. But can’t seem to find a solution in their documentation, or maybe I don’t comprehend some of the logic. A solution would be a way to either propagate the permission to all the files included in the folder it get’s picked or created… or to have the picker select all the children.
My preference is to continue with the Recommended scope https://www.googleapis.com/auth/drive.file . And it might be that the folder contains thousands of individual files multiple levels in, so it’s not a solution to manually pick the files. Any thoughts on this would be greatly appreciated, thank you!
A possible solution for your situation...
Is to create the folder in a shared drive.
Therefore, even though new files are added/updated/removed you will still be able to see all the updates and retrieve the information needed as you will have constant access to this folder.
Another solution which is more cumbersome...
Is to ask for user's permission and to re-authorize the application each time they are using it so in the case a new file is added you will have access to it.
Reference
Drive API v3 shared drives;
Drive API v3 manage shared drives.
The first approach I tried was to create the folder from the app. The problem is that I am only able to list the folder itself, but NONE of the content. https://developers.google.com/drive/api/v3/folder
The issue is probably the scope you authorized the user with. If you authorized with read only access your not going to be able to create you need full drive access to do that.
If you are using https://www.googleapis.com/auth/drive.file then you should create a folder with that and then create a file in the folder that i believe should work.
The second approach was to use the Google Picker API. There the client can choose which folder(s) to give us access to. However we can only get access to the folder, and none of the children folders/files. https://developers.google.com/picker/docs
There is no way to request access for a single folder or files. Its all or nothing really unless you use the https://www.googleapis.com/auth/drive.file scope which would only give you access to the files that your application created.
The product I'm working on currently uses the scope "https://www.googleapis.com/auth/drive" (which is now "restricted" by Google), which gives full read and write access to a user's Drive account, including app metadata. But we only need read access to list all files and folders inside a specific folder, and we need to be able to download those files, that's all.
Google Drive API will soon apply the new "restricted" scope policy (https://support.google.com/cloud/answer/9110914#restricted-scopes), which will require us to go through a very expensive audit (tens of thousands of dollars...). Is there a possible workaround to get 'read-only' access on a specific folder, and avoid the audit (note that https://www.googleapis.com/auth/drive.readonly is also a restricted mode)?
I'm aware of the "https://www.googleapis.com/auth/drive.file" scope (which is "recommended" by Google, so no audit required), which almost solves this problem. But we have thousands of users bringing in data from multiple Drive Folders, and pushing new files daily. This scope would introduce a manual step for a client each morning to have to "approve" every new file, and this would be a big scalability/usability problem.
Ideally, I would like Google to add a new scope, like a read-only access to anything inside a folder, before they go forward with their audit... but i doubt that this will happen soon.
Does anyone know of a better option?
[EDIT] For reference, here is the list of scopes and we can see which ones are "restricted", "sensitive" and "recommended" : https://developers.google.com/drive/api/v2/about-auth
Solution
Hi! So after taking a better look at this it seems that restricted scopes do NOT require any paid audit. The main difference is that they will have a wider access to user's data and thus it requires you to go through a restricted scope verification process.
You can use these restrictive scopes (the one that best fits your application) without the need of paying any audit. See more information about how to implement restrictive scopes here.
We want to migrate all google drive docs from one domain to other domain. While i got some links on how to transfer ownership of files but the sharing of new transferred files is being nullified . Is there any way to preserve sharing properties also while we transfer?
I think it's currently NOT possible.
As noted in Set file sharing permissions, files inherit sharing policy if transferred within same organization of the file owner. As mentioned:
Files always inherit sharing policy from the organizational unit of the file owner. A file may therefore inherit a new sharing policy if the owner moves to a new organizational unit or if file ownership is transferred to someone in a different organizational unit.
With this, new file owner might need to share files and folders.
Hope that helps!
Please suppose a situation. Organisation has a shared folder, with many people having access to sub folders some should not be able to edit/delete documents, but they should still be able to view and add documents to a folder.
Subsequently they should be able to share their own document with anyone (from the main folder "share list") but should not be able to share a document they were asked to join.
In Google Drive, Sharing settings offer 3 options depending on the user to restrict access. Each document CREATED in a shared folder inherits the share preferences of the parent folder. However, each document's access settings can still be managed individually and changed accordingly as well. Following are the 3 options and the access they provide to users:
Can Edit - With this option the user has access to edit, delete and share the doc
Can Comment - With this option the user in neither able to edit, nor delete or share the doc. However, they can view and insert comments to the doc.
Can View - Users can see the file but they can't comment on it or edit it.
In both, Option 2 & 3, Users are not able to share the doc but they are able to request for access in case they want the doc to be shared with someone. This request will go to the owner of the document. For more info, please take a look at this link.
Users with access to the parent folder might be able to see the document in the list, but if they haven't been given access to the document, they will not be able to open it. However, they might be able to request access to that document. Such access requests are forwarded to and handled by the owner of the document.
This link might help shed more light on the matter as well.