The documentation clearly states that this endpoint supports $expand to modify the search result:
users/{user-id}/drive/root/search(q='{search-text}')?$expand=permissions
But the request returns the following body in its response:
{
"error": {
"code": "notSupported",
"message": "The request is not supported by the system.",
"innerError": {
"request-id": "30fc9988-6f4f-46ba-a5b4-91b150c4a1a5",
"date": "2017-11-17T02:30:49"
}
}
}
This is also the case for other relationships. Though trying to expand createdByUser results in a BadRequest.
We want to do this request to avoid doing subsequent requests. Because at the moment we use a SharePoint ListItemUniqueId (due to backwards comparability) to find the corresponding DriveItem. Then we want to retrieve the permissions of this DriveItem. But right now we need to do two requests to achieve this.
We also can't use /users/{user-id}/drive/items because it does not support $filter.
Are we misunderstanding the docs or is this an issue on the Microsoft Graph side?
You cannot expand the permissions collection. From the documentation:
The permissions relationship of DriveItem cannot be expanded as part of a call to get DriveItem or a collection of DriveItems. You must access the permissions property directly.
The reason $expand=createdByUser returns a BadRequest is because it is already expanded by default.
Properties that are not supported are in $expand on the /search endpoint are:
children - Since /search returns files, this logically wouldn't make any sense here.
lastModifiedByUser - included by default
content - logically the content of each file wouldn't make sense to be included in a collection of DriveItems
Thumbnails can be expanded however ($expand=thumbnails).
Related
We are building an application that integrates office 365 using graph APIs. We need to pull all the office 365 contacts into our system and needs to be in sync.
There is delta API in office to pull only delta changes. We found an issue like we can not pull extended properties(Which includes outlook MPAI fields like mobile phone, assistant phone, etc)
GET https://graph.microsoft.com/v1.0/me/contacts/delta
So office 365 expects the client to make extra API call to get extended properties for each contact?
Means if the user has 1000 contacts, the client has to make 1000 plus API calls to pull the contacts from office365?
There is another contact search API which supports extended properties in a single call. Can we use this to pull the delta changes?
GET https://graph.microsoft.com/v1.0/me/contacts?$filter=lastModifiedDateTime gt '2018-07-28T05:25:32Z'
Please advice us how we can effectively pull office365 contacts
Thanks in advance!
As far as i can see (and observed myself with calendar events) expand is not supported for most delta query calls. See doc for delta query under Optional Query Parameters:
$expand is only suported for the manager and members navigational property for users and groups respectively.
Your filter request is also not supported for delta query. If u use :
GET https://graph.microsoft.com/v1.0/me/contacts/delta?$filter=lastModifiedDateTime gt 2018-07-28T05:25:32Z
You get the following error:
"error":
{
"code": "ErrorInvalidUrlQuery",
"message": "The following parameters are not supported with change tracking over the 'Contacts' resource: '$orderby, $filter, $select, $expand, $search, $top'.",
"innerError":
{
"request-id": "da1174b3-d...",
"date": "2018-08-06T12:45:34"
}
}
Funnily enough select is actually supported (contact delta doc).
Any way it seems like your only choice is to expand the normal contact request for a user.
If there are a lot of changes, you could try batching the expanded contact requests.
In Graph Explorer if i make a request to:
/v1.0/users/[User.Id]/drive/root/children?$select=*,sharepointIds
I do not get back the sharepointIds property from MS Graph.
If I remove * from select query parameter and only request sharepointIds property then I get the sharepointIds property and its values.
v1.0/users/[User.Id]/drive/root/children?$select=sharepointIds
I would expect $select=*,sharepointIds to return both the default properties and the sharepointIds in the same response.
Is there another working way for the clients to request additional properties from Microsoft Graph without typing all of the property names in the object one by one including the default properties?
The underlying OneDrive API seems to handle select=*,[propertyName] correctly.
This isn't possible today. Microsoft Graph currently doesn't support wildcards in a $select query parameter. Each property you want to return must be explicitly listed in the $select.
This is from the category "unexpected behavior" - take the following query (you can paste it in Graph Explorer):
https://graph.microsoft.com/v1.0/users?$filter=idc eq 'test'
This returns status code 400 and "Property 'idc' does not exist as a declared property or extension property." Which is a sensible and understandable response.
Now, if try to $select this property:
https://graph.microsoft.com/v1.0/users?$select=idc
I get a result I totally don't expect:
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#users(idc)",
"#odata.nextLink": "https://graph.microsoft.com/v1.0/users?$select=idc&$skiptoken=cut",
"value": [
{},
{},
...
{}
]
}
(a list of empty objects; asking for a single user with that invalid property name returns me an emtpy response).
So my question is - why does $filter error out and $select does not? Would there be a way to force $select to error out too? (eg I am using the /beta endpoint and a property name changes - I want my code to fail to find out)
Sorry for the late answer. We had a discussion on this and would love to get some of your thoughts (and the thoughts of other developers). We don't have a clear answer on this yet.
There are 2 schools of thought here:
Make $select and $filter behave consistently when dealing with properties that don't exist.
It's OK for these to differ in behavior, since the caller’s intent when specifying $select is likely different than that of $filter. The service cannot ignore a property specified in $filter because it completely changes the set of objects that are returned. However, $select does not change the set of objects but only drops the properties that are not available. Hence $select and $filter do not need to be consistent.
Thoughts?
Hope this helps,
How to count number of items in EntitySet of MicrosoftGraph, for example 'users' or 'groups'? I tried:
https://graph.microsoft.com/v1.0/users?$count
Returns: lists all users
https://graph.microsoft.com/v1.0/users/$count
Returns:
{ "error": { "code": "Request_BadRequest", "message": "Unexpected segment Edm.Int32.", } }
Also in Annotations of target "microsoft.graph.directoryObject" which are those EntitySets based on I see that it is Selectable=false, Countable=false ...
Will $skip be ever available on 'users' or other toplevel EntitySet items ( https://graph.microsoft.com/v1.0/groups?$skip=5 ) ? It is available on other items ( https://graph.microsoft.com/v1.0/me/contacts?$skip=5 ). I know about $skipToken, but it is not the same.
Can I find somewhere in the $metadata if property is sortable? For example user.displayName is sortable, but user.mail or user.givenName are not. This would be handy in the $metadata. Is there plan to introduce this into $metadata?
OrderBy DESC in this formula https://graph.microsoft.com/v1.0/users?$orderBy=displayName%20desc is ignored, it shows items ordered ASC, am I doing something wrong?
Not much help I know, but if you do an API call that gets a Collection you can get a count using the second form you gave in the first question. Eg:
https://graph.microsoft.com/v1.0/users/<id>/events/$count
returns the count (6 in my case, and not in JSON - the returned data is actually "\x{ef}\x{bb}\x{bf}6" (in Perl formatting)). If we use the ? as the last separator (which is what http://graph.microsoft.io/en-us/docs/overview/query_parameters seems to indicate we should) with this URL:
https://graph.microsoft.com/v1.0/users/<id>/events?$count
I just get the list of events with no count as you do.
So that seems to indicate two things to me:
a) The $count doesn't appear to work as a query parameter, despite the documentation and the OData standards saying it should,
and
b) There seems to be a bug in the API for handling EntitySets which isn't there for Collections.
Sorry I can't be of more help, but its another data point at least (I just came unstuck with the same thing which is why I noticed this StackOverflow post!)
Ad 1. https://graph.microsoft.com/v1.0/users/$count is the correct OData syntax (http://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/part2-url-conventions/odata-v4.0-errata02-os-part2-url-conventions-complete.html#_Toc406398087), but as indicated in the metadata directoryObject collections are not currently countable. ODataV4 also allows $count in query parameters (http://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/part2-url-conventions/odata-v4.0-errata02-os-part2-url-conventions-complete.html#_Toc406398166), but then it should be specified with true or false value (e.g. https://graph.microsoft.com/v1.0/me/events?$count=true) and the response will include both the collection and its count in the #odata.count property. This is again not supported for directoryObject collections.
Ad 2. There is no plan right now to support $skip for directoryObject collections.
Ad 3. Yes, we plan to indicate which properties are sortable by in metadata using the SortRestrictions annotation defined in the OData capabilities vocabulary (http://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/vocabularies/Org.OData.Capabilities.V1.xml)
Ad 4. Your request is correct, but we only support sorting users by displayName in the ascending order.
I'm posting a create item http request the to the graph api ("\children") to create a folder under a groups files, but I'm getting the following error:
"code": "-1, Microsoft.SharePoint.Client.InvalidClientQueryException",
"message": "The property 'description' does not exist on type 'oneDrive.item'.
Make sure to only use property names that are defined by the type."
It does not allow description to be part of the the request body json, even though the documentation says it is a read-write property on the item type.
Please help anyone!?:) The description field could be really valuable to store additional info about a folder or file.
The description property isn't support for OneDrive for Business right now, which is why this call fails. If you create a folder without the description property the call should succeed. I've made updates to the documentation to remove the description property from the docs until it's supported for OneDrive for Business.