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.
Related
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.
I'm trying to implement a shared filespace on an existing server that has its own login/authentication system. I'd prefer if I could use Google Drive or One Drive as the actual backing file store since then the files could (ideally) be edited in browser and automatically update for everyone else that has access to the shared area.
Diagrammatically (red link = existing authorization, red dashed line = desired auth in a session):
The need for this weird scheme stems from usage by a group where almost the entire set of members gets replaced each year (university committee). It was decided we don't just want to use a Google Drive folder since these end up in people's personal Google Drive folders, files get lost of cleared out etc. Additionally we already pass through this website quite regularly so it makes sense as an official repository of committee documents.
However this leaves me stuck with the issue in the diagram. I don't think that the server can create new, temporary tokens for a logged in user for them to pass to the Google Drive API to edit files. The question is really, can I get the Google API to do this for me somehow by only talking to the server? If not, what's the best way to implement this?
Thanks!
In the Google Drive UI, it reports on activities related to changes in the metadata (specifically, the Title changing).
However, looking at the results of using revisions.list on the file doesn't seem to generate a revision for the Title change. I don't see any other endpoint that seems to provide anything. The changes.list endpoint will show all changes in Drive, which is overkill to just get info for a file. Similarly, changes.watch will let me get notifications of changes, but I want to see the history of changes. Am I missing something?
The Apps Activity API gives you the same information of your screenshots
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!
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.