I created a dropdown in my application that displays folders in a Google Drive based on a user's search. The dropdown shows both the name of the folder and the last modified date. However, Google does not update the last modified date of the parent folder when any of it's child folders/files are modified, it only updates in response to direct modifications to that specific folder. I've thought of two possible solutions, but I'm not really of fan of either and am looking for some other more performant/efficient solutions.
For example,
After receiving the results from the user's query I could iterate over each result (i.e. each parent folder) and fetch a list of all it's children and then iterate through the last modified date for each child to return the most recent date. However, performing this on each autocomplete query would be slow and degrade the user experience as the user would have to wait for a few seconds after typing before the results load.
I could have a separate background process outside of my application that runs every 1 minute and checks for file changes using the Changes: list resource and filters the changes that are related to the root folder where the dropdown options live. However, to do this I need to recursively travel up the parent tree to get to the root folder for each change because only the direct parent (not other ancestors) are accessible in the "parents" property of the File resource. I'd have to do this for each change just to determine if the change was related to a subfolder/file of the root folder (2-3 levels up). Which means each change would require another 2-3 api requests just to determine if it is even relevant. Keep in mind the number of changes in the change list is quite large.
Both of these solutions while viable seem pretty inefficient to me. Does anyone have a better suggestion as to how I can achieve this objective?
Related
I am building an expressjs application using the google drive api that notifies the user whenever there is a file change in their google drive through webhooks. However, i am also receiving webhooks when i open/view a folder or a file, which is completely unnecessary. Is it possible to only receive webhooks whenever a new file is created or deleted in the drive? And if so, how do i do it?
There is no direct way unfortunately.
You will likely have to make another request once your app has been notified of a change. Its possible you may have to persist some data to compare with depending on what you need to do exactly. The watch endpoint, as you have seen, will notify you of almost every change, including views. So you'll need to find a way to filter these out.
If you are trying to get create/deleted times only then I would suggest taking the file id from the change notification and making a request to get the file metadata and seeing if the file was created in the last 5 minutes (or less) for example. You can speed this up by only getting the createdTime field for instance.
For deleted, you can either get the type of change directly from the change notification, but this will only notify you if you have deleted it permanently i.e. not in the trash. Trash events look just the same as the others. If you need trash notifications, it is going to be more complicated. There is a trashed attribute, but not a timestamp for it. If you need this then you will probably have to keep a snapshot of which files are trashed and then every time you get a request, check to see if the file that changed is now trashed.
There is an active feature request for this
Support event type filtering for Changes watch channel
Go and give it a ☆ to let Google know that you want this feature!
I need to get a list of all changed items in my project in BIM 360. Can I do this using forge-api.
Ho, regarding with the latest question [If my service is not available and I will miss some webhook events, how can I get all the changes that were made after the last webhook event received] :
If your requirement is to know which items are changed in one folder of Docs, Search API with filter can be of use. e.g. the endpoint below will return all items which are updated since a certain time.
https://developer.api.autodesk.com/data/v1/projects/{{project_id_with_b}}/folders/{{one_folder_id}}/search?filter[attributes.lastModifiedTime]-ge=2019-10-15
More filters options are described at
https://forge.autodesk.com/en/docs/data/v2/developers_guide/filtering/
While if you wanted to know all updates in one call, I do not see currently the way is available. While, Activity API is on the way, it might be helpful to know all activities during a certain dates, then you could filter out what you are interested in and locate the corresponding module>>files/resources etc.. but Activities may probably be categorized with specific scopes e.g. admin activities, project actives, issue activities etc. so it is not one call knows all updates.. And these APIs may not be exposed in the same time.
I have to retrieve my file changes upto a particular time.i can see Google provide drive changes api which will give me changes after any start page token. But the requirement is to get history changes...can anyone please help me in this
Changes are always tracked relative to a start token, that's how the service works.
In other words, what you want to do is not possible.
You first need to call getStartPageToken and track changes from that moment, there is no other way around it. Otherwise there are no changes to track.
Depending on what specific information do you want to track, Revision methods might get you what you want. For each file you can get a list of historical Revisions by calling Revisions.list and for each individual revision you can get information like modified time, modifying user or links to the version of the file by calling Revisions.get.
I hope this is of any help.
I've written a test suite for my google drive api library and am witnessing some non-deterministic behavior. In the simplest case, I can insert a permission on a file, then immediately get a list of permissions on the file and I don't see the newly inserted permission.
I'm chalking this up to eventual consistency being eventual, but it would be nice to know if this is actually the case; the documentation makes no mention of consistency delays.
I can't see this documented anywhere but there is a simple experiment you can do.
Adding and removing permissions is an asynchronous and queued task in my opinion and eventual consistency is my observation too. You can confirm this with a GSuite for Business account by conducting a test as follows:
In the Drive UI, upload a folder tree structure with a root folder, 3 or 4 levels of sub-folders and 300 to 500 files. You may get away with fewer but this is how many I used.
In the Drive UI, share the root of those folders with another user on your domain.
In Admin Console > Reports > Audit > Drive, add Filters as follows:
Event name: User Sharing Permissions Change
User name: the email of the user you added in step 2.
Owner: your email
Date and time range:
From: add yesterday's date
To: add today's date and 23:59 as time
Press search. You should see hundreds of events - one for every file and folder you added in step 1. Each event shows the exact time stamp of the permission being added.
As you should see, the permissions are not added instantly. It can take many minutes/hours depending on the numbers involved and (I assume) indeterminate work going on in the Google cloud.
It is indeed. If you think about Google's infrastructure, it's all about read performance and data integrity through massive distribution. The inevitable consequence of that is that write performance is relatively poor and asynchronous.
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?
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.