I am trying to filter items when searching a SharePoint list, via the MS Graph API, where certain custom field values are met, and the content type is not a folder. For example:
/sites/mysite.sharepoint.com/lists/test/items?&select=name,contentType,webUrl,id&$expand=driveItem,fields&$filter=fields/MyColumn eq 'HelloWorld' and fields/ContentType ne 'Folder'
I have both the custom field and Content Type indexed, but I still receive:
{
"error": {
"code": "invalidRequest",
"message": "Field 'ContentType' cannot be referenced in filter or orderby as it is not indexed. Provide the 'Prefer: HonorNonIndexedQueriesWarningMayFailRandomly' header to allow this, but be warned that such queries may fail on large lists."
}
}
I have used the above Prefer header and that does return data, but seems wrong that I have to supply such a value when the column is indexed. Is there something I am missing with this or is there a compatability problem with the Content Type column within the MS Graph API? If there is, how can I work around it without having to use the Prefer header?
You need to provide the allowthrottleablequeries preference to execute this query, so you must provide request headers for this endpoint.
https://graph.microsoft.com/v1.0/sites/{site id}/lists/{list id}/items?$select=name,contentType,webUrl,id&$expand=driveItem,fields&$filter=fields/MyColumn eq 'HelloWorld' and fields/ContentType ne 'Folder'
Prefer: allowthrottleablequeries
Related
I am trying to fetch recently accessed items for a user using this endpoint. While fetching the items themselves works, I am unable to filter on lastModifiedDateTime, which is a property of the API response, as per this link.
I am making a GET request to the following endpoint:
https://graph.microsoft.com/v1.0/me/drive/recent?$filter=lastModifiedDateTime ge 2020-08-25T05:30:00Z
And I am getting a Microsoft.SharePoint.Client.InvalidClientQueryException with the following message:
'The expression "lastModifiedDateTime ge 2020-08-25T05:30:00Z" is not valid.'
Please help!
The error which is showing up says 'The expression "lastModifiedDateTime ge 2020-08-25T05:30:00Z" is not valid' which means the expression which you have given in the filter is not right. You need to correct it as shown below.
https://graph.microsoft.com/v1.0/me/drive/recent?$filter=lastModifiedDateTime ge '2020-08-25T05:30:00Z'
But still this call doen't work because the filter is not supported on this property and you will end up 'Invalid filter clause'.
As a work around you can get the recent files and filter it on your end as most of the properties doesn't support filtering yet.
Need to execute and return 1st order detail alone for each order. Below doesn't work
https://services.odata.org/Experimental/Northwind/Northwind.svc/Customers?$expand=Orders($expand=Order_Details;$top=1)
Need to filter records based on order id. Below doesn't work and throws "Term 'Orders($expand=Order_Details)$filter=OrderID eq '10643'' is not valid in a $select or $expand expression"
https://services.odata.org/Experimental/Northwind/Northwind.svc/Customers?$expand=Orders($expand=Order_Details)$filter=OrderID eq '10643'
Invalid but returned results
https://services.odata.org/Experimental/Northwind/Northwind.svc/Regions?expand=Order_Details
https://services.odata.org/Experimental/Northwind/Northwind.svc/Regions?expand=Territories
Not Returning Childrens
https://services.odata.org/Experimental/Northwind/Northwind.svc/Products?&expand=Suppliers
https://services.odata.org/Experimental/Northwind/Northwind.svc/Regions?&expand=Territories
https://services.odata.org/Experimental/Northwind is no longer 'Best Practise'
It's a bold statement, but this question proves that many advanced query features have not been fully or properly implemented in the published service.
While many developers may use it to practise OData query concepts, given that the OData implementation is largely up to the developers and the version of the packages they use, it is probably a of more commercial value if you query against a live or a dev implementation of the actual service that you want to query.
The following is an analysis of OPs queries and how to achieve the desired response according the the OData-V4 specification and verified against a deployed API that utilises the following NuGet packages:
Microsoft.AspNet.OData v7.3.0
Microsoft.OData.Core v7.6.2
The actual API that I used for testing is proprietary and cannot be published here.
According to the spec, you have to move the $top specifier to the Order_Details expansion.
https://services.odata.org/Experimental/Northwind/Northwind.svc/Customers?
$expand=Orders($expand=Order_Details($top=1))
However:
https://services.odata.org/Experimental/Northwind does not correctly implement $top query option within expansion as defined in 5.1.3 System Query Option $expand
Query options can be applied to an expanded navigation property by appending a semicolon-separated list of query options, enclosed in parentheses, to the navigation property name. Allowed system query options are $filter, $select, $orderby, $skip, $top, $count, $search, and $expand.
$top is however supported in the ODataLib v7+ (.Net) implementation of OData v4. So the syntax is correct, but you should check with your API developers for their opinion if your queries with this syntax do not work.
NOTE: When using $top you should also use $orderbyto ensure that the query results are reliable and reproducable:
https://services.odata.org/Experimental/Northwind/Northwind.svc/Customers?
$expand=Orders($expand=Order_Details($orderby=ProductID;$top=1))
To apply multiple query options within an expansion, you must separate then with a semi-colon: ;. However that alone will not prevent other customer records from being returned, so you must also add a root level filter as well, which is complicated by the fact that Orders is a collection. We can use the any function to only return customers that have an order with the specified Id:
Also note that OrderID is numeric, so do not wrap comparison values in quotes
https://services.odata.org/Experimental/Northwind/Northwind.svc/Customers?
$expand=Orders($expand=Order_Details;$filter=OrderID eq 10643)
&$filter=Orders/any(o:o/OrderID eq 10643)
this can be further simplified using parameter alias:
https://services.odata.org/Experimental/Northwind/Northwind.svc/Customers?
$expand=Orders($expand=Order_Details;$filter=OrderID eq #orderId)
&$filter=Orders/any(o:o/OrderID eq #orderId)
&#orderId='10643'
However:
https://services.odata.org/Experimental/Northwind does not correctly implement parameter aliases so you cannot verify the alias syntax against this service.
Also note
that experimental service is not correctly applying the filter to either the root elements or the navigation collection, the syntax shown here does however work against the .Net ODataLib implementations of OData v4.
The reason that your $expand is not working is that you have left off the $ from the parameter name. The OData query interpreter only identifies query options are parameters that start with $.
Eitherway, according to the https://services.odata.org/Experimental/Northwind/Northwind.svc/$metadata#Regions, there is no Order_Details navigation property to $expand on:
<EntitySet Name="Regions" EntityType="NorthwindModel.Region">
<NavigationPropertyBinding Path="Territories" Target="Territories" />
</EntitySet>
So when you try again with the correct syntax:
https://services.odata.org/Experimental/Northwind/Northwind.svc/Regions?$expand=Order_Details
you get the expected message:
Could not find a property named 'OrderID' on type 'NorthwindModel.Region'
The second attempt will work if you put the correct $ in there for the $expand query option:
https://services.odata.org/Experimental/Northwind/Northwind.svc/Regions?$expand=Territories
The OData query parser only looks for the expected query options with the $ prefix, this allows your API logic to still process other non-OData parameters as you see fit to do so. The other parameters therefor are still HTTP Url compliant parameters, the implementation at odata.org doesn't know what to do with them and they are simply ignored.
This is just another variation on the same issue with 3, the $ is missing. (I suspect that this URL was meant to be in 3: https://services.odata.org/Experimental/Northwind/Northwind.svc/Products?$expand=Suppliers)
So while https://services.odata.org/Experimental/Northwind is not 100% reliable, neither are the .Net ODataLib, SAP or MS Dynamics implementations. The spec is evolving and there are many query techniques that are not fully implemented in probably any providers at this stage.
Simply be mindful of this fact and when you run into issues using an API, the first point of contact should be the developers or the community that are supporting that particular API, it will be up to the developers what techniques and packages they use and at the end of the day to what extent they support the protocol as it is specified.
I'm using ms-graph with SharePoint Online.
I've a simple list with a single title column and 3 items.
I use the following ms-graph call to filter items by title:
https://graph.microsoft.com/v1.0/sites/root:/lists/list-guid/items?expand=fields&filter=startswith(fields/Title,%27fig%27)
The result is an error message:
Field 'Title' cannot be referenced in filter or orderby as it is not indexed. Provide the 'Prefer: HonorNonIndexedQueriesWarningMayFailRandomly' header to allow this, but be warned that such queries may fail on large lists.
I know that this call was working before and also when I use SharePoint REST API then I can filter the list without any problems. I also tried different tenants.
Another fact is that the same call is working without the startswith filter.
Few days ago I had a different message for the same call.
"Field 'Title' cannot be referenced in filter or orderby as it is not indexed. Provide the 'allowthrottleablequeries' preference to allow this, but be warned that such queries may fail on large lists."
Regarding the following error:
Field 'Title' cannot be referenced in filter or orderby as it is not
indexed. Provide the 'Prefer:
HonorNonIndexedQueriesWarningMayFailRandomly' header to allow this,
but be warned that such queries may fail on large lists.
at least two options are available to surpass this error while filtering.
Option 1. Add an index to a SharePoint column
Once the index to a SharePoint column which participates in filtering is created, the error should no longer appear.
Option 2. Append header Prefer:HonorNonIndexedQueriesWarningMayFailRandomly
As the error message states append the specified header to request, for example in Graph Explorer:
Just checked the Graph API Explorer and found out that you can use allowthrottleablequeries rather than HonorNonIndexedQueriesWarningMayFailRandomly
Try to send your request with the following Request Header
Prefer: allowthrottleablequeries
I have developed an API using Microsoft Graph API. I am encountering below issue.
URL that I am calling :
/v1.0/sites/root/lists/cb32cc85-5351-423d-b2ec-bb418c1d9c64/items?
$filter=fields/Created gt '2018-1-1T00:00:00'
&expand=fields
&$orderby=createdDateTime
&$top=10
Error returned from the API :
Field 'Created' cannot be referenced in filter or orderby as it is not indexed. Provide the 'allowthrottleablequeries' preference to allow this, but be warned that such queries may fail on large lists.
How to enable allowthrottleablequeries as it says and how should I achieve this?
I'm afraid this isn't a very clear or useful error message. As far as I know, there isn't actually a way to enable allowthrottleablequeries.
This happens when a SharePoint list grows too large to handle filtering or sorting non-indexed columns. The fix is to add an index to the created column in your List Settings. You can find instructions on how to accomplish this in Add an index to a SharePoint column.
Try to send your request with following Request Header
Prefer: allowthrottleablequeries
If it does not work then try the following Request Header
Prefer: HonorNonIndexedQueriesWarningMayFailRandomly
I'm using Microsoft Graph to get a list of messages for a user.
I'm using the following URL
https://graph.microsoft.com/v1.0/me/mailFolders/inbox/messages
One important thing that is returned by this is the meetingMessageType when the message revolves around a meeting request.
I would also like to get the uniqueBody of the message. However, that's not provided by default. One needs to specifically ask for that field. I can do that by adding ?$select=uniqueBody to the URL.
However, that now means that I need to add the rest of the fields I want to the $select query parameter. That's not a big deal until I run into meetingMessageType. Microsoft Graph returns:
Could not find a property named 'meetingMessageType' on type 'Microsoft.OutlookServices.Message'.
What can I do to ensure I get both uniqueBody and meetingMessageType?
Try this:
$select=uniqueBody, microsoft.graph.eventMessage/meetingMessageType
Yogesh's answer is close but will result in a Only one level select is supported error.
As long as you don't care about the value of meetingMessageType, you can use this select:
$select=microsoft.graph.eventMessage, uniqueBody
You'll note that the results no longer include meetingMessageType as a property. The list however is limited to only those messages that are eventMessage, effectively giving you a result set filtered to only show meeting requests.