As i understand it a request for files.get only returns my own permissions on a file. How can i read all of them or at lest get a handle for all of the permissions to copy them to another file.
The use case would be an app which creates a related file alongside the original and wants to set the same permissions and sharing settings as the original file on the app created copy.
As you can see from previous questions, currently, this will not be possible for the restrictions you state. Sorry.
Google are aware of the importance of this feature and are working to resolve it as soon as possible.
I faced the same issue and this is the workaround I used.
1) Go to google contacts and add all the members into a custom/new group.
2) Select the file you want to share and instead of searching individuals type group label name and all the members would be automatically added.
Related
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.
I'm searching for a little while and I can't find what I'm looking for, so it may be a good idea to ask it here.
Is there a way to obtain, by API, for a specific file, the name of the last user (and timestamp) who accessed a file?
Goal: to write to script to know who access what on my drive.
Unfortunately, what you want cannot be achieved. The Drive Activity API is used only for retrieving the activity on the specified file. You can gather the users who have view access but not the ones who have actually viewed the file.
The action object from the Drive Activity API is represented by the action detail. For a document at the moment, the action details are the following: create, edit, move, rename, delete, restore, permissionChange, comment, dlpChange, reference, settingsChange. Therefore, taking these into account as well, you cannot see who viewed a file.
Since the option of seeing the actual viewers of a file is still a relatively new feature in the UI, the option for the API does not yet exist.
What you can do instead is to file a feature request on Issue Tracker by accessing this link here.
Reference
Drive Activity API
You can use the Drive Activity API.
We use the multi-linking of folders and documents in Google drive to share live updates with our whole team. This is very useful as each person gets access to the doc and any updates made are received in real-time.
The trouble we have is that if anyone decides to remove the multi-linked item from their home directory using the "remove" option, the content is trashed for everyone. This causes loss of data and info and is not acceptable. We do have the option of checking the location of the multi-linked item and removing it from that particular location alone. But not everyone follows this.
Is there any way we can do the settings such that the "remove" option works only on the current location for the multi-linked item? All ideas are welcome. Can we use Google App Script for this?
There is no workaround for this as of now.
However, you can file a Feature Request for this.
There is no way for you to alter how the google Drive web application works. Remove will remove it forever one.
We are having issues where sometimes a file that a user can access is not returned when the user issues a files.list. This can happen in many ways. For example, new members of a Google group will not see previously shared files, as described in this question. Moreover, acording to Google documentation there are other limits on sharing which can prevent shared files from appearing in the "Shared with me" view. Finally, a user can issue a files.delete on a file she doesn't own, and the file will disappear from files.list but will still exist.
What can a user do via the SDK alone to cause a file which she can access via files.get to appear in the list of files retrieved via files.list? We are using a service account which impersonates users; the user never authenticates to Google via a browser. A link in an email that the user needs to click won't work for us, unfortunately. Accessing the file via the Google Drive UI has the desired effect, but the analogous files.get call does not.
The Google Calendar API explicitly exposes a CalendarList interface where a user can issue an insert to add an existing calendar to her list. The Google Drive SDK seems like a hybrid Files/FilesList interface with some of the functionality missing (nothing like FilesList.insert) and some of the functionality mixed together (issuing a delete as a non-owner acts like FilesList.delete but issuing it as the owner acts like Files.delete).
If we can't manage the user's files list programmatically then it is not useful for our service. We could ignore the files.list call entirely and just start recursively performing children.list queries on all shared folders, but this is incredibly expensive (unless someone knows how to issue a single query which returns all the Files resources in a folder and not just the IDs of those resources).
Any help would be appreciated. We've been trying this many different ways and have been frustrated at every turn. Thanks!
In Google Drive, when puting a file into a folder, the ACLs of the folder are added to the ACLs of the file.
Is there a way to avoid that? In my use case, a lot of user have "Can View" access on the folder, but only a subset of those will ultimately allowed to view that file. Even if we quickly follow with an ACL update request, there will be a short amount of time during which the visibility of the file is too broad for my use case.
Note that a solution involving having a short period of time during which the access is more limited that what it will ultimately be would be acceptable. Also, I am ready to use either Drive API or Document List API.
This might help
I was so happy when I found it! Unfortunately, it still cannot override file settings, in the case of a document owned by someone else than the containing folder's creator.