I am using the Python Client to permanently delete collections (not move into trash but permanently delete).
The version of python gdata is 2.0.16.
Here is the code that I am using to permanently delete a collection:
delimited = folder_entry.GetEditLink().href.split('?')
url = delimited[0] + '?delete=true'
client.Delete(url, force=True)
The issue that I am experiencing is what happens to the documents that were inside the collection that is being deleted.
This API used to (up until about the beginning of April 2012) not delete the documents that were inside the collection. The end result would simply be that the documents that were inside the deleted collection would be 'untagged' from the collection.
Currently, this API work completely different in terms of the documents located inside the deleted collection. Now, the documents inside the deleted collection will also be permanently deleted.
A few questions...
1) Is this change to the API expected?
2) Is there a new way to permanently delete a collection and simply 'untag' the documents that were located in that collection.
Thank you for any information.
Dan
I think this has less to do with how the API behaves but with how the whole product behaves.
With the move from Google Docs to Google Drive we've moved from collections used as "tags" to collections being "folders" and now, when deleting a folder, all the contained files are also deleted. The API reflects that behavior as a side-effect it seems.
Unfortunately I don't think much more work will be done on the Document List API as we are hard at work on the next version of the Drive API which should cover most of its features.
Related
The official Graph API documentation states that it is possible to:
search within a folder hierarchy
However, the entire drive is searched when we perform a folder scoped search like the following:
https://graph.microsoft.com/v1.0/me/drive/root:/Folder:/search(q='file')?select=name,webUrl,driveId
This has been discussed here [2] but either this has changed in the last year or did not work in the first place.
Is this a bug or intended behaviour? Can we scope the search to a single directory?
Reference
[1] https://learn.microsoft.com/en-us/graph/api/driveitem-search?view=graph-rest-1.0&tabs=http
[2] How to search an item in specific folder in one drive?
Using IMAP, how can I figure out if a mailbox has been moved or deleted by another client?
The LIST command simply does not list a deleted mailbox any more.
Exactly. You have to remember what folders you know about. Next time you do a LIST, any that are missing have been deleted.
Additionally, you should be tracking every folder's UIDVALIDITY value. If it changes, that folder is not the same one you know about. It may have been renumbered, deleted and recreated, or deleted and replaced by a renamed folder.
In either case, you should dump any cached information you know about that folder.
There is not, in general, any way to track folders that have been renamed by another client. You can only detect that a folder is missing and there is a folder with a new name. IMAP simply does not provide enough information to correlate them. Tracking messages and folders across moves does not appear to have been a design goal of IMAP.
I have created a module in Orchard cms, in which I created a form to collect the data and also added a image field(media). Now I have created a separate view(.chtml) to display the list of data that are collected from form in module in admin section.
Now suppose I added few data, let it be two entry in the form and I display all the two entry in newly created separate view. But When I delete the one of entry in form in admin section, it deleted and disappear there, but it is still present in database and visible in my newly created separate view. Can anyone please help me to know, how to detect the delete entry in Orchard Cms Database. I think it is soft deleted, because it is still in database but not showing in admin view section (dashboard).
Yes, Orchard always does soft deletes on content items. There are two boolean flags - Published and Latest - kept in table Orchard_Framework_ContentItemVersionRecord for each version. If both are false, the version is considered deleted. If there is no published and latest version for a given item, the whole item is considered deleted.
If a deleted item still appears in your custom view, you're probably doing some custom query in your code and you may need to revisit it. ContentManager fetches published versions by default (Get and Query methods) only.
I've built an integration using the Google Docs API (using GData) allowing users to create/edit documents from another application. Originally, when documents were deleted we would have them permanently deleted. They were no longer visible in Google Docs or Google Drive. Now when they are deleted using the Google Docs API, they are still present in the list of Documents in Google Drive. When you attempt to follow the link to the document you arrive at the "Sorry, the page (or document) you have requested does not exist." page.
Does Google Drive not honor the actions taken via the Google Docs API? Do I need to delete these documents using both the Google Docs API and the Google Drive API? What if the user has not migrated to Google Drive? Is there a way to tell if the have migrated? Or do I force them to migrate so I can use the Google Drive API to keep their Google Drive clean of these dead documents?
The Drive API and the Docs List API both operate on the same resources so you only have to use one of them (and we recommend the former).
With the Drive API you can trash or delete files. When you trash a file, it will still be listed in Google Drive with a label to mark it as in trash, so that you can still untrash it.
If you want to remove a file completely, you have to use the delete method.
I was having the same problem and I believe this is some kind of caching on the drive UI.
The file does appear to be deleted correctly and is not visible to the drive API.
The orphaned stubs eventually get deleted as the cache is cleared every so often.
I found that by removing the file from the parent and then deleting it meant that it was easier to see what was going on when using the drive UI whilst testing my app.
service.children().delete(folderId=parent_id, childId=file_id).execute()
service.files().delete(fileId=file_id).execute()
I was facing the same problem while using Google Drive APIs. I think when the Delete api deletes the document, their is still some linking with parent folder remains, so the browser renders the document. when I tired to delete the document with below piece of code, it properly works for me.
DriveService.Childern.Delete(parentResId, fileId).Fetch(); // fileId=>ResourceId of document to be deleted
This is a caching issue, the file has actually been removed. If you try to open the file in the Drive UI you should see something along the lines of "Sorry, the file you have requested does not exist."
It will clear itself soon.
We use extensively (from an application) in the Document List API the fact than a file / document can be assigned to more than one collection, in order to work in a similar way that labels. Has this been deprecated? At least from the web user interface, only one folder can be assigned to one file.
Working fine here and multiple collections can be successfully assigned.
Right click a file, Choose "Organise" and check the box next to each collection you want the document to be a part of.