I have seen a few examples of folks using the Picker to select files and demonstrating that once the file is selected, it can be read, etc. But I am curious for how long the app's access to the file lasts once it has been picked. Is it indefinite? If not, how long does it last?
And as a corollary, how does the Drive API "know" that the file I'm reading was just selected by the picker? Does it keep track internally somehow? I don't see any kind of token that gets passed to the API request. But maybe I'm missing it.
This might answer your second question: "how does the Drive API "know" that the file I'm reading was just selected by the picker? Does it keep track internally somehow?"
Google Drive REST API uses IDs to identify files and folders. The API
does not provide file or directory pickers
The file pickers identify files by URI and don't know anything about
file IDs. Querying the files by name in order to get the id of the new
file may fail as there may be duplicates in another or even the same
folder.
But for your first question wherein
how long the app's access to the file lasts once it has been picked.
Is it indefinite? If not, how long does it last?
This doesn't seem to have any documentation for how long does Drive Picker provides access to the file, but I assume this is relevant to how Drive API authorizes requests stated here on this documentation
Related
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.
I'm trying to create script to download all files from another user shared folder in google drive using rest api. If i'm right, there are two variants:
Using drive.children.list, with folder ID
Using drive.files.list, with search query like 'FOLDER_ID in parents'
But both of this variants returning only files which were once opened by my google account in browser. If I open file in browser - this file will appear in results of API calls.
Folder is shared for anyone, who has link.
Where is the problem, how I can list all files in folder?
Since you did not give us any info about the SCOPE, I am wild-guessing that it may be your problem. You probably have FILE scope, instead of DRIVE.
Also, I would recommend to test these things with 'TryIt!' here. You can quickly modify both scopes and queries there.
Good Luck
This is a bug/quirk in the Drive API, though there is an easy workaround. If you call files.update with 'addParents=root' it'll add the shared folder under 'My Drive'. This has the effect of making the files part of your corpus and they'll appear in results.
My expectation is that if I query the Changes Feed with a scope of drive.file, I will only receive changes to files owned by my application.
However, in testing that I have done, I am seeing files in the feed that have nothing to do with my app. At least some of them are files that have been shared with me.
Anybody know exactly how this is supposed to work?
Edit 0
Similar or duplicate StackOverflow questions
Listing files with search query returns out-of-scope results (drive.files.list call, using drive.files scope)
List ignores drive.file scope and shows shared files not created by the calling app
The files returned will not be specific to your app. Files that are "public on the web" are also reported back, regardless of whether or not your app created them or they were ever opened by the user in your app.
There is a parameter (includeSubscribed) that will filter out shared docs but this is also a bit limited (see below).
From Detect Changes:
For Google Drive apps that need to keep track of changes to files,
polling repeatedly can be both inefficient and resource-intensive. The
Changes feed provides a more efficient way to detect changes to all
files, including those that have been shared with a user. The feed
works by providing the current state of each file, if and only if the
file has changed since the given changestamp.
Here is a relevant parameter from Changes:list.
includeSubscribed boolean
Whether to include shared files and public
files the user has opened. When set to false, the list will include
owned files plus any shared or public files the user has explictly
added to a folder in Drive. (Default: true)
Scope(https://www.googleapis.com/auth/drive.file)
Meaning(Per-file access to files created or opened by the app)
The scope https://www.googleapis.com/auth/drive.file strikes this balance in a practical way. Presumably, users only open or create a file with an app that they trust, for reasons they understand.
But though, to your point, please refer to this q&a.
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!
I'm aware of shortcut links. Looking for behavior similar to that of a native Google doc. File exists, possibly takes up storage, can be renamed/moved/deleted, but the data inside shouldn't be modified except by the app. Possibly, defining export formats/links.
I believe the answer is a simple "no" - Google Drive is for storing user files, not protected application data or configuration data. So you could put a file to a users drive, but only the owner of the drive can control whether the file is shared or changed. So they can edit it, you can't stop them, and there's no reason to think that'll ever be a feature in the future.
To have such control you will need to store such data on your own server, or some other such storage medium.
The only other thing that you would do with only Google Drive is encrypt the configuration file you store, for instance, so it couldn't be easily edited - but that's probably just a bad idea. If you must save a configuration file to a persons drive, bury it inside an application folder and sanity check it to ensure it isn't corrupt - but don't count on a person or application never opening and editing it. If it's something a person shouldn't be able to read or change, don't save it to their drive.
As of April 2012, application data is supported: What is the Application Data folder?.
"Export format links" could be done with Custom file properties, though, I'm unsure of what kind datatypes are supported for the value beyond the example string.