Graph REST API - Search inside DriveItem not working for non-mainstream file extensions - microsoft-graph-api

I've been trying to search within a specific DriveItem folder but I've been having some troubles. First of all, despite the API stating that "You can search within a folder hierarchy, a whole drive, or files shared with the current user.", I haven't found any documentation supporting this. I have found this stackoverflow reply that describes how to do it. Unfortunately, it doesn't to be working very well.
Since I don't know how sensitive IDs are, I'll be redacting them in my examples.
https://graph.microsoft.com/v1.0/me/drive/items/<id_parent_folder>/children?select=name
This request returns all files inside the folder I want to search and it does list everything inside the folder. The response is something like:
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#users('<id_user>')/drive/items('<id_parent_folder>')/children(name)",
"value": [
{
"#odata.etag": "\"{redacted1},1\"",
"name": "automation_csv.csv"
},
{
"#odata.etag": "\"{redacted2},1\"",
"name": "HOSPITAIS_PT.cpg"
},
{
"#odata.etag": "\"{redacted3},1\"",
"name": "HOSPITAIS_PT.dbf"
},
{
"#odata.etag": "\"{redacted4},1\"",
"name": "HOSPITAIS_PT.prj"
},
{
"#odata.etag": "\"{redacted5},1\"",
"name": "HOSPITAIS_PT.qpj"
},
{
"#odata.etag": "\"{redacted6},1\"",
"name": "HOSPITAIS_PT.shp"
},
{
"#odata.etag": "\"{redacted7},1\"",
"name": "HOSPITAIS_PT.shx"
}
]
}
However, when searching inside the folder I only get the CSV file....
https://graph.microsoft.com/v1.0/me/drive/items/<id_parent_folder>/search(q='')?select=name
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#Collection(driveItem)",
"value": [
{
"#odata.type": "#microsoft.graph.driveItem",
"name": "<name_parent_folder>"
},
{
"#odata.type": "#microsoft.graph.driveItem",
"name": "automation_csv.csv"
}
]
}
Searching for any other file name produces no results.
Is this a bug or a feature? Is there another endpoint that allows me to search all files inside a folder?
EDIT: changed the "beta" endpoint to "v1.0", though they produce the same results. Just don't want to create the assumption that it only happens in the beta endpoint.

Use the Microsoft Query API to search instead of using q search parameter.
See https://learn.microsoft.com/en-us/graph/api/resources/search-api-overview?view=graph-rest-beta

Related

How can I parse email addresses from Sharepoint DriveItem permissions?

So I've been trying to get email addresses of people that have access to certain files in a Sharepoint document library of a site through the use of the Microsoft Graph API. Below is an example of how my permission object looks like, which is retrieved from https://graph.microsoft.com/v1.0/sites/<site id>/drives/<drive id>/items/<item id>/permissions.
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#sites('...')/drives('...')/items('...')/permissions",
"value": [
{
"id": "...",
"roles": ["owner"],
"grantedTo": { "user": { "displayName": "testsite - Eigenaars" } },
"inheritedFrom": {}
},
{
"id": "...",
"roles": ["read"],
"grantedTo": { "user": {"displayName": "testsite - Bezoekers"} },
"inheritedFrom": {}
},
{
"id": "...",
"roles": ["write"],
"grantedTo": { "user": { "displayName": "testsite - Leden" } },
"inheritedFrom": {}
},
{
"id": "...",
"roles": [
"write"
],
"grantedToV2": {
"siteGroup": {
"displayName": "Developers",
"id": "120",
"loginName": "Developers"
}
},
"grantedTo": {
"user": {
"displayName": "Developers"
}
},
"inheritedFrom": {}
},
{
"id": "...",
"roles": ["owner"],
"grantedTo": {
"user": {
"email": "testsite#mysharepoint",
"id": "uuid",
"displayName": "testsite - Eigenaars"
}
},
"inheritedFrom": {}
}
]
}
I assume the testsite in the displayName property is a group name (probably the group that belongs to the site the file resides in), but I have seen cases where I can't find this group name in the groups retrieved from the /groups endpoint in the Graph API.
You can also see the group Developers, which I haven't managed to find in the full group list retrieved from /groups.
The documentation around this is quite vague and unclear to me. Somewhere I read that this lack of data could be due to authentication scopes, but I have "god mode" administrator rights in this Sharepoint environment, so that would seem strange to me.
My main goal is to be able to get all users that have access to a specific file.
Thanks in advance!
1. I assume the testsite in the displayName property is a group name, but I have seen cases where I can't find this group name in the groups retrieved from the /groups endpoint in the Graph API.
This is because as per Drive Item Permission >> Identity Set >> Identity resource type Quoting
The identity's display name. Note that this may not always be available or up to date. For example, if a user changes their display name, the API may show the new value in a future response, but the items associated with the user won't show up as having changed when using
This can explain why sometimes you don't see the group name in your groups.
I suggest you use the id.
2. My main goal is to be able to get all users that have access to a specific file.
Do you have any users that appear on the Has Access section of the drive item on sharepoint? For users you should be able to get permissions and use the ids to Get directoryObject using the id values from grantedToIdentitiesV2 or grantedToV2 which will return odate type.
GET https://graph.microsoft.com/v1.0/directoryObjects/{id}?$select=id
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#directoryObjects(id)/$entity",
"#odata.type": "#microsoft.graph.group or user or application",
"id": "id"
}
For groups, the users would be the members of the group.

Microsoft graph not creating embed link for file

While posting request to microsoft graph:
POST 'https://graph.microsoft.com/v1.0/me/drive/root:/017_2018-08-12_18.47.27.jpg:/createLink'
content-type': 'application/json
{
"type": "embed"
}
I am only getting
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#permission",
"#odata.type": "#microsoft.graph.permission",
"id": "5o98ENjWYH2pNK8wO5_d7QHUrdk",
"roles": ["read"],
"shareId": "s!AgDP2w-bgvZL****evpaN2yel",
"link": {
"type": "embed",
"webUrl": "https://onedrive.live.com/embed?resid=4B****U"
But according to documentation, I should also get WebHtml with Iframe link not only webUrl, and this is what I am looking for so I can generate links for photos, and put them on website.
Am I doing something wrong or is there any way around so I can get same embed url that I can generate from manualy clicking in onedrive?
I'm using personal one drive account.
Trying this out on the graph explorer does not work on the v1.0 endpoint for me. However using the beta endpoint does indeed return the webHtml property like as follows
Essentially what you would need to do is change the v1.0 segment in the url to beta.
POST 'https://graph.microsoft.com/beta/me/drive/root:/017_2018-08-12_18.47.27.jpg:/createLink'
content-type': 'application/json
{
"type": "embed"
}
And you should get back something like this
{
"#odata.context": "https://graph.microsoft.com/beta/$metadata#permission",
"#odata.type": "#microsoft.graph.permission",
"id": "p6z1ZAtRqKFwqHNVfaa6mPFQIyI",
"roles": [
"read"
],
"shareId": "s!AorKRTkoJljsixZbAANWreQhS7gk",
"expirationDateTime": "0001-01-01T00:00:00Z",
"hasPassword": false,
"link": {
"type": "embed",
"webUrl": "https://onedrive.live.com/embed?resid=EC5826283945CA8A%211430&authkey=!AFsAA1at5CFLuCQ",
"webHtml": "<iframe src=\"https://onedrive.live.com/embed?resid=EC5826283945CA8A%211430&authkey=!AFsAA1at5CFLuCQ\" width=\"98\" height=\"120\" frameborder=\"0\" scrolling=\"no\"></iframe>"
}
}

Is it possible to get full path to a OneDrive item?

I'm using the MS Graph SDK in a C# project to search through people's OneDrives for specific terms in files and folders. When I find one, I've not found a way to get the full path for a DriveItem?
Not the URL path, but the file system path where the owning user stores the file locally.
Is this possible?
When you request the metadata for a drive item you receive for example:
{
"#microsoft.graph.downloadUrl": "https://m365x214355-my.sharepoint.com/personal/meganb_m365x214355_onmicrosoft_com/_layouts/15/download.aspx?UniqueId=c8b43b37-bc76-4352-af27-5a8e9f1bbfeb&Translate=false&tempauth=eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIwMDAwMDAwMy0wMDAwLTBmZjEtY2UwMC0wMDAwMDAwMDAwMDAvbTM2NXgyMTQzNTUtbXkuc2hhcmVwb2ludC5jb21AZGNkMjE5ZGQtYmM2OC00YjliLWJmMGItNGEzM2E3OTZiZTM1IiwiaXNzIjoiMDAwMDAwMDMtMDAwMC0wZmYxLWNlMDAtMDAwMDAwMDAwMDAwIiwibmJmIjoiMTUzMzg5NzE3MiIsImV4cCI6IjE1MzM5MDA3NzIiLCJlbmRwb2ludHVybCI6IitjMlZ4YU9UY2hCSEhmK3hyNlhrMExtd0pRMEhQR0hYMmlKaTBMRldhTHM9IiwiZW5kcG9pbnR1cmxMZW5ndGgiOiIxNjkiLCJpc2xvb3BiYWNrIjoiVHJ1ZSIsImNpZCI6Ik16VTVOVFkyWVRjdFlqazVOeTAwWlRsa0xUZ3hNV1V0TlRNMU5UZGhaRGc0WkdVeSIsInZlciI6Imhhc2hlZHByb29mdG9rZW4iLCJzaXRlaWQiOiJaRGd5TXpFeVpqa3RZakl6WWkwMFkySmpMVGsxWkRVdE0yVXdaRGswWlRZNFl6RmwiLCJhcHBfZGlzcGxheW5hbWUiOiJhcGlzYW5kYm94cHJveHkiLCJhcHBpZCI6IjAwOTFlNTllLTE3ZTgtNDdmMC1hNDUwLTQ0M2Q0ZGQzYTAwNiIsInRpZCI6ImRjZDIxOWRkLWJjNjgtNGI5Yi1iZjBiLTRhMzNhNzk2YmUzNSIsInVwbiI6Im1lZ2FuYkBtMzY1eDIxNDM1NS5vbm1pY3Jvc29mdC5jb20iLCJwdWlkIjoiMTAwM0JGRkRBMzgxMzFBRiIsInNjcCI6ImFsbHNpdGVzLnJlYWQgbXlmaWxlcy5yZWFkIGdyb3VwLnJlYWQgbXlmaWxlcy5yZWFkIGFsbHNpdGVzLnJlYWQgYWxsc2l0ZXMucmVhZCBteWZpbGVzLnJlYWQgYWxscHJvZmlsZXMucmVhZCBhbGxwcm9maWxlcy5yZWFkIiwidHQiOiIyIiwidXNlUGVyc2lzdGVudENvb2tpZSI6bnVsbH0.eWQzcTFxNmhBb0txNFNnZzQyNlIyU2gzaUQwSGJxbC9abWRlVVZ3OGUwMD0&ApiVersion=2.0",
"createdDateTime": "2017-08-07T16:17:44Z",
"eTag": "\"{C8B43B37-BC76-4352-AF27-5A8E9F1BBFEB},2\"",
"id": "01BYE5RZZXHO2MQ5V4KJB26J22R2PRXP7L",
"lastModifiedDateTime": "2017-08-07T16:17:44Z",
"name": "Camera Customer Analysis.xlsx",
"webUrl": "https://m365x214355-my.sharepoint.com/personal/meganb_m365x214355_onmicrosoft_com/_layouts/15/Doc.aspx?sourcedoc=%7BC8B43B37-BC76-4352-AF27-5A8E9F1BBFEB%7D&file=Camera%20Customer%20Analysis.xlsx&action=default&mobileredirect=true",
"cTag": "\"c:{C8B43B37-BC76-4352-AF27-5A8E9F1BBFEB},1\"",
"size": 2675045,
"createdBy": {
"user": {
"email": "MeganB#M365x214355.onmicrosoft.com",
"id": "48d31887-5fad-4d73-a9f5-3c356e68a038",
"displayName": "Megan Bowen"
}
},
"lastModifiedBy": {
"user": {
"email": "MeganB#M365x214355.onmicrosoft.com",
"id": "48d31887-5fad-4d73-a9f5-3c356e68a038",
"displayName": "Megan Bowen"
}
},
"parentReference": {
"driveId": "b!-RIj2DuyvEyV1T4NlOaMHk8XkS_I8MdFlUCq1BlcjgmhRfAj3-Z8RY2VpuvV_tpd",
"driveType": "business",
"id": "01BYE5RZ6TAJHXA5GMWZB2HDLD7SNEXFFU",
"path": "/drive/root:/CR-227 Project"
},
"file": {
"mimeType": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet",
"hashes": {
"quickXorHash": "qz9+NLaGwZCFBcd9gH+HCNUVcn8="
}
},
"fileSystemInfo": {
"createdDateTime": "2017-08-07T16:17:44Z",
"lastModifiedDateTime": "2017-08-07T16:17:44Z"
}
}
As you can see it contains a parentReference which contains the path
To get the full path, substring the path starting at the first : and append the name.
In the above example it would give: /CR-227 Project/Camera Customer Analysis.xlsx
Doc reference
However, getting the local path where the user stored the file locally is not stored by Microsoft. But you can reproduce it because the OneDrive file structure will be the same as the local one.
Based on my test, we can't use the Graph API to get the root directory of the OneDrive local file system. We can only get the relative path of the OneDrive item.
My test configuration: local storage directory: C:/onedrive. The file is stored in “C:/onedrive/Test Floder/”. We can only get the “path /drive/root:Test”.
enter image description here
The repro steps:
We can try the following API to get the relative path for the user's OneDrive settings first:
https://graph.microsoft.com/v1.0/me/drive/items/{item-id}/children .
Then, you can stitch the file system path set by the user with the relative path obtained from the API.
We can set different file system paths on the local system for OneDrive. You can refer to this article to set the local storage location for OneDrive.

Drive entity no longer returns a driveType attribute

I'm observing a change in functionality in Microsoft Graph. When requesting a list of drives from a SharePoint site, I used to see a driveItem attribute that no longer seems to be present as of Nov 14.
The site documentation mentions the relationship to the drives collection.
The drive documentation describes the driveType attribute as:
Describes the type of drive represented by this resource. OneDrive personal drives will return personal. OneDrive for Business will return business. SharePoint document libraries will return documentLibrary. Read-only.
Here is an example call:
https://graph.microsoft.com/v1.0/sites/{site-id}/drives
Response:
client-request-id →d822c749-baf6-4857-abd9-6d80f70823d9
request-id →d822c749-baf6-4857-abd9-6d80f70823d9
x-ms-ags-diagnostic →{"ServerInfo":{"DataCenter":"EastUS","Slice":"SliceB","Ring":"NA","ScaleUnit":"003","Host":"AGSFE_IN_28","ADSiteName":"EST"}}
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#drives",
"value": [
{
"createdBy": {
"user": {
"displayName": "System Account"
}
},
"createdDateTime": "2015-05-22T17:21:01Z",
"description": "This system library was created by the PointPublishing feature to store application pages.",
"id": "b!a4YqXM4QKkOPmOj73xfdss5bbYPr7MlFlXKVhtK0Dpjf4OJPyoBFQo2-YK5095t1",
"lastModifiedDateTime": "2015-05-22T17:21:03Z",
"name": "AppPages",
"webUrl": "https://mysharepoint.sharepoint.com/portals/hub/AppPages",
"quota": {
"deleted": 0,
"remaining": 0,
"total": 0,
"used": 0
}
}
<snipped a few values>
]
}
Is the change in functionality I am seeing here by design or non-intended?
Edit: When attempting the call:
https://graph.microsoft.com/v1.0/sites/root/drives?$select=id,driveType,Name
The driveType is returned
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#drives(id,driveType,name)",
"value": [
{
"id": "fakeId",
"name": "Documents",
"driveType": "documentLibrary"
}
]
}
When requesting drives for a site based on the site-id (/sites/{site-id}/drives) we see different attributes returned.
Just closing the loop on this. As Brad mentioned, an issue has been identified. A fix is currently in the pipeline and should be rolling out soon.

Google Cloud Endpoints REST Discovery Document missing format

I've upgraded to Cloud Endpoints 2.0 which no longer supports RPC. Therefore, I generated a new discovery document and used the service generator with the REST discovery doc as input in order to generate the client library for my iOS app.
Using the new REST discovery doc I am getting the following error when trying to generate the library:
~/workspace/google-api-objectivec-client-for-rest/Source/Tools/ServiceGenerator/build/Release/ServiceGenerator discovery/servUsApi-v1-rest.discovery --outputDir GTLAPI --gtlrFrameworkName GoogleAPIClientForREST
ERROR: Failure, exception: Looking at parameter 'creditKickbackKash:creditAmount', found a type/format pair of 'number/(null)', and don't how to map that to Objective-C
I was able to manually fix this by adding (in numerous places) in the discovery doc, the "format": "double" key and value for all double parameters. Notice creditAmount below is missing a format, like all other doubles.
The generated discovery doc looks like this:
"creditKickbackKash": {
"httpMethod": "PUT",
"id": "servUsApi.admin.creditKickbackKash",
"parameterOrder": [
"userId",
"creditAmount"
],
"parameters": {
"userId": {
"format": "int64",
"location": "path",
"required": true,
"type": "string"
},
"creditAmount": {
"location": "path",
"required": true,
"type": "number"
}
},
"path": "creditKickbackKash/{userId}/{creditAmount}",
"response": {
"$ref": "ResultDTO"
},
"scopes": [
"https://www.googleapis.com/auth/userinfo.email"
]
}
Is anyone else having this issue? How can I get the discovery document generation to properly format the document including double number types?
I had the same problem. I rolled back from 1.9.50 to 1.9.48 and the problem is gone.

Resources