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?
Related
I’m using the graph api from a c# app to access SharePoint. I need to get a list of all folders and sub folders. I have tried getting the drive item and then iterating through the children looking for folders and then recursively working through the list but it’s too slow.
I have also tried this end point
https://graph.microsoft.com/v1.0/sites/{site-id}/lists/{list-id}/items?$expand=fields&$filter=fields/ContentType eq 'Folder'
With this header
Prefer: HonorNonIndexedQueriesWarningMayFailRandomly
But it returned that the query would consume too many resources.
Is there a way to
A. Get the folders more efficiently or
B. Do a search to return folders or
C. Only list folders in the children endpoint
You can call this endpoint to get all files and folders in the specific library:
https://graph.microsoft.com/v1.0/sites/{site-id}/lists/{list-id}/items?$expand=driveItem
Is it possible to use the microsoft graph api to get the id of a folder within a sharepoint document library? If so, how?
I can see in the documentation that I can get the path of a folder and/or file, and make queries based on this path. But what I would like is to get an id, so if the folder and/or file ever changes name, I can still query that specific folder and/or file. Is this possible?
Specifically, I am creating an internal dashboard for my employees. We have a Folder in a sharepoint document library called "Contacts". Within this "Contacts" folder we have n number of subfolders such as "John Doe," "Jane Doe," etc. If an employee is viewing the information for John Doe within our internal employee dashboard, I'd like to display the any child folders and/or files of John Doe.
Again, all I can find in the graph api documentation is how to query based on the relative path. I'd like to be able to use the API to get an id for any folder and/or file, as well as to return any child objects of any folder using the id (and not the relative path). How can I do this?
Yes it is possible. You should use the below query
https://graph.microsoft.com/v1.0/sites/{siteid}/drives/{document libraryid}/items/{folderid}/children.
If you want to get the folder id use this call
https://graph.microsoft.com/v1.0/sites/{siteid}/drives/{document libraryid}/root/children and get the id of the folder
I try to search for files on SharePoint Document Library (e.g. the default 'root'). I created a few test-files by uploading them or create new Office files online and made some search-requests, e.g. https://graph.microsoft.com/v1.0/sites/root/drive/root/search(q='{query}') and until yesterday everything worked fine.
Now I started to edit files on SharePoint or created/uploaded new ones and with this edited or new files, I have the problem that I get no result when I search for them. "old" files, I created when I started I find although, as long as I don't edit them.
To get access I registered an App inside the AAD and gave it the needed permissions (
Sites.Read.All, Sites.ReadWrite.All, Files.Read.All, Files.ReadWrite.All
and a direct access to a specific file with https://graph.microsoft.com/v1.0/sites/root/drive/items/{item-id}/ works also well.
Search will read data from indexed data, but crawling and re-indexing of a library need to take some time. So you the code return null for the new files:
https://graph.microsoft.com/v1.0/sites/root/drive/root/search(q='{query}')
The following code get the library data directly but not based on the indexed data, so it works well.
https://graph.microsoft.com/v1.0/sites/root/drive/items/{item-id}/
When retrieving folders list with Outlook REST API (beta endpoint)
https://outlook.office365.com/api/beta/me/MailFolders
I get the complete list of folders. But I also get some hidden/ignored folders that are not displayed in usual Outlook clients. I would like to ignore such folders as well.
I tried to forge a request using SingleExtendedProperty and PigTagAttributeHidden
https://outlook.office365.com/api/beta/me/MailFolders?$select=Id,DisplayName,ParentFolderId,ChildFolderCount,UnreadItemCount,TotalItemCount,SingleValueExtendedProperties&$expand=SingleValueExtendedProperties($filter=(PropertyId eq 'Boolean 0x10F4'))
In the results this property is always marked as false even for these "ignored" folders.
Is there another way or fix to achieve this?
I went through the folders reported, and none of them were hidden. Basically they fell into two categories:
System folders like Sync Issues and Conflicts. These aren't hidden, but OWA doesn't show them in it's folder view. OWA handles these specially. The suggestion for a REST app that wants to also handle these specially and not show them is to check the WellKnownName property. All of these have a constant value for that property, so they can be selectively filtered.
Add-in folders. These were created by a module extension add-in. They actually reside in a folder structure like:
/WebExtAddIns (Hidden)
|__/{GUID id of addin} (Hidden)
|__/{Name of module extension tab} (Visible)
The REST API includes the {Name of module extension tab} folder because it's marked visible, even though it's parent folder is hidden. I've reported this to our developers and we are investigating improving this scenario. In the meantime, you can filter these out by making sure that the ParentFolderId matches either the Id of another folder in the folder results OR the ParentFolderId of the Inbox folder.
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.