I'm using Make (formerly Integromat) to remove permissions on Folders, files and subfolders using Google Drive APIs.
When removing permissions on a folder (either through the UI or the API), Google will recursively remove like permissions from any files in that folder and any subfolders. There is naturally a propagation delay whilst this process completes.
So far so good.
Drive will necessarily leave some file and subfolder permissions intact where those permissions were specifically granted on that/those objects. We therefore need to iterate through those files and subfolders, checking for any residual permissions and removing them with the Remove Permissions API.
The problem here is that there is no way to determine whether permission removals are still being processed (propagated) from the parent folder. THe only (crude) way I can think of dealing with this is to introduce a fixed delay time between permission removals. If the delay time isn't long enough, Remove Permissions returns an error when trying to remove a permission which has already been removed.
Has anyone dealt with this in a more effective way?
Related
Scenario
There are many files in a Google (Team) Drive, all of which are nested in folders
All of these folders and their files are deleted by mistake.
In an attempt to recover the data, the Restore button on the Web UI is used
The Restore button in the Web UI does not seem to care about the order, and restores files before restoring the folders that contained them.
Thousands of files end up in the root directory of the drive since their folders "don't exist" when being restored from Trash.
What I need:
How can I recover the information about where the files used to reside, in order to patch this correctly?
What I tried:
Get all of the revisions for one of the files in question with Revisions: list and see there is only 1 result.
Get the revision information for that revision with Revisions: get
Realise that the revision information contains nothing about parents.
Get the file information with Files: get
Confirm that the head revision meta matches the only revision found in step 1
See that the file meta shows the parent is the root.
I can't find a way of determining what the original folder was for the trashed and incorrectly restored file.
After further investigation I don't think it is possible to recover the information about the previous parents from the Google Drive API v3.
However, if you are using Google Team Drive, as part of the G Suite, you should have access to the G Suite Admin SDK Reports API unless you are on a G Suite Basic account. With that you can use Activities: list with various filters to pull back the information about where the orphaned files came from.
I have published my solution here: Google Team Drive Orphaned File Restorer
This console application can pull a list of Google Drive file movements between two points in time, optionally filtered by the IP Address of the user who made the changes (i.e. restored the files from trash). It will then use that information to re-parent the files in question. You can do a dry run to see what the changes will be before you actually commit.
I shared a folder containing files and subfolders with files with multiple users and gave them edit permissions. One users account has modified the viewing ability(?) of every file and subfolder they had access to. From my account when I open the top level folder I see it empty but I know these files are still there because I own the majority of them and my drive storage amount hasn't changed.
The user claims they have no idea how it happened so maybe that it was an app they unknowingly gave drive access to?
Is there any way I can fix this from the Google Drive web interface? I found Google Apps Scripts has access to the Drive API, should I find a script that can mass change the permissions?
Only the owner can delete the file.
The files were removed from the folder but were not deleted.
Therefore, they take up disk space.
To view files outside the folder, follow these steps:
https://drive.google.com/drive/search?q=is:unorganized%20owner:me
Excuse my bad English
Venca
A non-privileged Google Drive user has accidentally removed a large number of files from folders shared across an organisation. They do not have permission to delete the files entirely, because they are not the owner. However, users with edit permissions are able to remove a file from a shared folder. This returns the user to the owner, but seems to leave the file orphaned without a parent folder.
The files were owned by various different users.
How do I restore these files to their correct folders? The Google Drive Audit Log does not contain enough information to restore the folders correctly - the parent folder ID is not included with the "Remove from folder" event.
Google Drive is included in the Reports API of the Google Apps Admin SDK. It provides similar information to the Google Drive Audit Log, but with additional metadata. That includes the parent folder ID of files which were removed.
To restore the files you should first query the Reports API for files removed by the user in question over the relevant time period, using the Activities:list method.
Then you'll need to setup a Google Apps service account (which is a little confusing), to allow you to impersonate the owners of the documents that were removed.
Lastly, you can iterate over the event report for the removed files and use the Files: patch method in Google Drive REST API, to re-add the parent ID's to each of the files.
See Gist Using Google Drive API to restore files removed from shared folders
for example of the last step.
Google Drive has a cool feature: one can add a file or folder from Shared With Me to My Drive.
Then I can delete this file from My Drive in the same manner (note that if I delete shared file in web version it won't go to Trash)
However, I am getting 403 Forbidden error while trying to delete this file using Google Drive API (because of insufficient permissions due to that I am not owner of this file). So, as one can see, this is not a simple Delete request. How can I implement this functionality?
Add to My Drive changes the parents collection for the item in question. To change this, you will want to unparent the item rather than delete.
Use the about.get call to retrieve the My Drive ID, then remove that ID from the list of parents in the file resource for the file/folder. Update the file with the new list of parents.
A late answer, but I ran into this issue too. This happens because the file isn't actually copied, it's the same instance. If you remove it from My Drive, it will be removed from the Shared Drive too. And you may lack permission to remove it from the Shared Drive.
If you want to just remove it from My Drive: click on the file. In the right panel, under Details, there is a list of locations. At least the Shared Drive and My Drive is listed there. Click the X to remove it from My Drive, and it will disappear there while preserved on the Shared Drive.
This is what I found. After removing the parent of an item shared with me, do a sharedWithMe search still return the item, even though the item's parent list is empty.
Here is the code:
string sItemId = (this is the Id of the item shared with me);
string sParentId = driveService.About.Get().Execute().RootFolderId;
driveService.Parents.Delete(sItemId, sParentId).Execute();
var parentList = m_driveService.Parents.List(sItemId).Execute();
At this point parentList.Items.Count is 0.
Now when I search sharedWithMe the item is in the return list.
This is what I did. I have following hierarchy.
Folder A
Folder A\Folder B
Folder A \Folder C
Folder B has nothing in it
Folder C has a file in it which I uploaded through API
I have no problems deleting Folder B but when I delete Folder C. This is the error I get.
{"Google.Apis.Requests.RequestError\r\nThe authenticated user may not have granted the app 1068466789052 write access to all of the children of file 0B6SoKHS5o1IJV0lmV19qYkVWX3c [403]\r\nErrors [\r\n\tMessage[The authenticated user may not have granted the app 1068466789052 write access to all of the children of file 0B6SoKHS5o1IJV0lmV19qYkVWX3c] Location[Authorization - header] Reason[fileAccess] Domain[global]\r\n]\r\n"}
I'm guessing that you are using drive.file scope?
Three thoughts ...
Are you sure that the app that the created the file and folders is exactly the same app that is attempting the deletion?
If the answer to (1) is 'yes', then it's probably a bug. I get a whole bunch of issues with drive.file scope.
As a workaround, try changing to drive scope.
Another bug I've seen is where you try to delete a folder with more than 100 children. Your question says there is only one child file, but there could be more children in trash. The workaround for this bug is to do your own recursive deletion.
See What can cause "The authenticated user may not have granted the app 69xxx995 write access to all of the children of file 0B6Bxxx",?