Graph delta tokens can be placed on drive root folders. For OneDrive root folders, the delta request will return an item when a public link is added on the folder. But for Sharepoint site root folders, this doesn't happen. No item is returned when fetching a delta.
Not sure if this is a bug or a missing feature.
This is a limitation of the feature currently. There is an existing uservoice entry that you can vote for. It'll also keep you up to date with any decision/progress.
Related
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
My app is using client_credentials, and is successfully consuming the Graph API on most calls.
However, I have been attempting to get images from a sharepoint folder by path and filename:
https://graph.microsoft.com/v1.0/drive/root:/sites/folder1/folder2/folder3/folder4/photo.jpg
The appropriate headers are being set (authorization and accept).
httpClient.DefaultRequestHeaders.Add("Authorization", "Bearer " + session["access_token"]);
httpClient.DefaultRequestHeaders.Add("accept", "application/json; odata.metadata=minimal");
The request returns a 404 - Not found response.
When I navigate to our sharepoint site, I can see the image fine so I can only assume the file path is correct:
https://ourcompany.sharepoint.com/sites/folder1/folder2/folder3/folder4/photo.jpg
Apologies, but I am new to Graph API and couldn't find anything referencing this in the documentation:
https://learn.microsoft.com/en-us/graph/api/resources/onedrive?view=graph-rest-1.0
Path
/me/drive/root:/path/to/file
Resource
Access a DriveItem by path relative to the user's OneDrive root folder.
Are there special permissions needed for this? I found something suggesting permissions might be required in azure portal but this is to do with azure active directory and I'm not sure if it will affect the graph API, as it was working OK, reading drives and drive items in sharepoint (by drive id and drive item id, not by file path).
EDIT: Went into azure portal, added Graph API permissions to application:
Site: ReadAll
Directory: ReadAll
File: ReadAll
No change so far.
A site contains the drive so you're referencing things in the wrong order. To get a DriveItem from a site's drive, you want this:
/sites/{siteId}/drive/root:/folder1/folder2/folder3/folder4/photo.jpg
If you're looking to download the DriveItem instead of just retrieving the metadata, you'll want this:
/sites/{siteId}/drive/root:/folder1/folder2/folder3/folder4/photo.jpg:/content
How do I find a file that was deleted and had a relative path of /foo/baz.txt?
I am using the /v1.0 endpoint and my app requests the Files.ReadWrite.AppFolder scope. I can access /drive/special/appRoot.
Will /drive/special/appRoot:/search(q='baz.txt') find deleted files?
Will /drive/special/appRoot:/foo/baz.txt:/versionsversions for a deleted file?
There is not a lot of examples (or documentation support) for using AppFolder.
I'm afraid this isn't possible today.
When a file is deleted from OneDrive (either via the Web App or the API), it is sent to the Recycle Bin and held for 30 days (assuming the user doesn't manually empty it of course).
At the moment, it isn't possible to access or restore a DriveItem from a dive's Recycle Bin (this has been discussed but I'm unaware of any ETA). The only way to restore an item today is for the user to do so via the OneDrive Web App.
According to your description, I suppose you want to get a file that was deleted in App Folder.
Based on my test, we can use the following API to get the file in App Folder:
/drive/special/approot:/foo/baz.txt:/
However, if we deleted the file, it will return a 404 status code when we use this API.
We can get the file by using this API unless we restore it in the Recycle bin of OneDrive.
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.