Using MS Graph API /beta endpoint to figure out if the list has been updated/changed.
Used the following query first:
https://graph.microsoft.com/beta/sites/xxxxx.sharepoint.com:/sites/xxxxx?$expand=lists(select=id, name, system, lastModifiedDateTime)
And did get the following date:
"lastModifiedDateTime": "2018-10-08T10:23:37Z",
But when going against the items and see the dates on the latest item with the following query:
https://graph.microsoft.com/beta/sites/xxxxx.sharepoint.com,92af4fbc-04bc-46d8-9c78-f63832fbf48a,1b59d85a-41bd-4498-a64c-17bd13069d90/lists/b9c39323-076a-4ae7-942b-1d0060a6b352/items
you can see the dates:
"createdDateTime": "2018-10-08T10:23:37Z"
"lastModifiedDateTime": "2018-10-08T10:29:14Z",
You can see that lastModifiedDateTime property on the list looks like actually lastCreatedDateTime?
Best Regards,
Kim
edit:
First graph request gets the SitePages list and its lastModifiedDateTime:
{
"id": "b9c39323-076a-4ae7-942b-1d0060a6b352",
"lastModifiedDateTime": "2018-10-08T10:23:37Z",
"name": "SitePages",
"system": {}
},
But if we then look at the items of the list, we can see that it has an item with a higher lastModifiedDateTime (second graph request):
"createdDateTime": "2018-10-08T10:23:37Z",
"eTag": "\"27e03a98-9321-4586-8ef1-0b5323c26730,6\"",
"id": "8",
"lastModifiedDateTime": "2018-10-08T10:29:14Z",
We can also see that the createdDateTime of the listitem is the same as the list lastModifiedDateTime. Looks like a bug in the api to mee. The date in the first request should be "2018-10-08T10:29:14Z". Dont you agree?
As your description, I assume you want to know why the LastModifyDateTime is different.
Base on my test, your first link is to get the lastModifyDateTime of the special site,
but your second link is about the items of the b9c39....
We can use the MS Graph Explore to check whether this two site has some differences.
Indeed, it appears to be a bug, for List resource lastModifiedDateTime property returns invalid value, it seems to be mapped to the last list item date and time when the item was created (ListItem.createdDateTime)
It could also be confirmed as a bug using the following endpoints (in both examples a valid lastModifiedDateTime value is returned):
https://graph.microsoft.com/beta/sites/{site-id}/lists/{list-id}/drive/root?select=lastModifiedDateTime
https://tenant.sharepoint.com/_api/web/lists/getbyid({list-id})?$select=LastItemModifiedDate
Meanwhile as a workaround the following solution could be considered to enumerate site lists:
https://graph.microsoft.com/beta/sites/{site-id}/drives?expand=root(select=lastModifiedDateTime)
where root/lastModifiedDateTime returns a valid value
Limitation: Only returns document libraries
Related
I am working with both EWS and the Graph API.
I would like to create events (online meetings with skype/teams) in an calendar that is already available via EWS.
To match the calendar to the one available via Graph API i try to use https://learn.microsoft.com/en-us/graph/api/user-translateexchangeids
The calendar i created has this id when returned by the FindFolder call:
<t:FolderId Id="AAMkAGNiY2YxMjY3LTUxYjgtNGI1Yy1hOTM2LTU4MTM5OTZiNjdjYgAuAAAAAABW2gY0kRG1SqggDTNZN6i8AQAPJkKZ1XJkQ6huFmcVa6XaAAGixNZ3AAA=" ChangeKey="..."/>
<t:DisplayName>Test</t:DisplayName>
I create a request to the graph api:
{
"inputIds": [
"AAMkAGNiY2YxMjY3LTUxYjgtNGI1Yy1hOTM2LTU4MTM5OTZiNjdjYgAuAAAAAABW2gY0kRG1SqggDTNZN6i8AQAPJkKZ1XJkQ6huFmcVa6XaAAGixNZ3AAA="
],
"sourceIdType": "ewsId",
"targetIdType": "restId"}
and get the result
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#Collection(microsoft.graph.convertIdResult)",
"value": [
{
"sourceId": "AAMkAGNiY2YxMjY3LTUxYjgtNGI1Yy1hOTM2LTU4MTM5OTZiNjdjYgAuAAAAAABW2gY0kRG1SqggDTNZN6i8AQAPJkKZ1XJkQ6huFmcVa6XaAAGixNZ3AAA=",
"targetId": "AAMkAGNiY2YxMjY3LTUxYjgtNGI1Yy1hOTM2LTU4MTM5OTZiNjdjYgAuAAAAAABW2gY0kRG1SqggDTNZN6i8AQAPJkKZ1XJkQ6huFmcVa6XaAAGixNZ3AAA="
}
]
}
However, if i call https://graph.microsoft.com/v1.0/me/calendars i get a different id
"id": "AAMkAGNiY2YxMjY3LTUxYjgtNGI1Yy1hOTM2LTU4MTM5OTZiNjdjYgBGAAAAAABW2gY0kRG1SqggDTNZN6i8BwBIq5JjIBY-RqWQllrF0GSkAAAAB353AAAPJkKZ1XJkQ6huFmcVa6XaAAGixNowAAA=",
"name": "Test",
Is there a way to match the (ews) calendar i already have to the one returned by the Graph API?
This is a shot in the dark, because I've never dug this deeply into the weeds on the Graph Ids, but you might try calling Graph with the header that selects "immutable ids." I tried to find some details on what this actually means without much luck.
The header is:
request.Header("Prefer", "IdType=\"ImmutableId\"");
HTH, and if not, sorry for guessing.
I'm sending a search request to the /me/drive/root/search endpoint. I'm specifying which fields to return using the $select query parameter as follows:
https://graph.microsoft.com/v1.0/me/drive/root/search(q='sdflkdshflkjhsdf')?$select=webUrl,name,lastModifiedDateTime,createdBy,lastModifiedBy,createdDateTime,folder,image,id
However the drive item objects returned are missing some of the fields I requested. For example here is the response to the above query:
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#Collection(driveItem)",
"#odata.nextLink": "https://graph.microsoft.com/v1.0/me/drive/root/search(q='sdflkdshflkjhsdf')?$select=webUrl%2cname%2clastModifiedDateTime%2ccreatedBy%2clastModifiedBy%2ccreatedDateTime%2cfolder%2cimage%2cid&$skiptoken=s!MTtlMDIzYmJlYi03NmUwLTRmMGUtYTljMy02MmE0MTNiM2RlZDE",
"value": [
{
"#odata.type": "#microsoft.graph.driveItem",
"createdDateTime": "2017-08-03T12:59:28Z",
"id": "01ZGVHW2FL7NNJJOD5AVGIMHTNV2BTATLB",
"lastModifiedDateTime": "2017-08-03T12:59:28Z",
"name": "sdflkdshflkjhsdf.pdf",
"webUrl": "https://[REDACTED].sharepoint.com/personal/oscar_[REDACTED]/Documents/sdflkdshflkjhsdf.pdf"
}
]
}
As you can see the createdBy and lastModifiedBy fields have not been returned. Are these fields not supported on this endpoint? The documentation says the endpoint returns full DriveItem objects which should include these fields.
I had same issue. In documentation is said, that
Drive Recent
Drive Item search that both should return the same object DriveItem.
When I tried to search
https://graph.microsoft.com/v1.0/me/drive/root/search(q='MY_RECENT_DOC.docx')?$top=1
gave me response without createdBy or lastModifiedBy.
But when i used 'recent API', the same object with the all information was presented.
https://graph.microsoft.com/v1.0/me/drive/recent?$top=1
Like #oscar-robinson said you can use id (what is always visible) and this id you can use to another search where all information will be presented.
https://graph.microsoft.com/v1.0/me/drive/items/{id}
We are querying data using MS Graph OData API, but I found msGraph presents nextlink unexpectedly.
For example, even though I intend to query only one record by specifying $top=1:
https://graph.microsoft.com/v1.0/users?$top=1
in the response there is a #nextlink, which leads to another query to this link by our tool.
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#users",
"**#odata.nextLink**": "https://graph.microsoft.com/v1.0/users?$top=1&$skiptoken=X%2744537074020001000000223A4164616D73404D333635783231343335352E6F6E6D6963726F736F66742E636F6D29557365725F36653762373638652D303765322D343831302D383435392D343835663834663866323034B900000000000000000000%27",
"value": [
{
"id": "6e7b768e-07e2-4810-8459-485f84f8f204",
"businessPhones": [],
"displayName": "Conf Room Adams",
"givenName": null,
"jobTitle": null,
"mail": "Adams#M365x214355.onmicrosoft.com",
"mobilePhone": null,
"officeLocation": null,
"preferredLanguage": null,
"surname": null,
"userPrincipalName": "Adams#M365x214355.onmicrosoft.com"
}
]
}
One can reproduce it in graph-explorer
Is it working as expected?
I think there should be no nextlink since I only want one record. Is this a bug?
Using $top=x doesn't actually mean
I want you to show me only first x record(s) and ignore the rest
Its role (based on the query parameter docs) is:
Sets the page size of results.
What you saw is the expected outcome, as using $top is one of the cases where paging is used:
Some queries against Microsoft Graph return multiple pages of data either due to server-side paging or due to the use of the $top query parameter to specifically limit the page size in a request.
And further:
When a result set spans multiple pages, Microsoft Graph returns an #odata.nextLink property in the response that contains a URL to the next page of results.
Which precisely answers your question. If you want. feel free to read more about paging here.
Also remember that while using $top query parameter it's a good practice to remember about sorting (source: OData official documentation).
I am using MusicBrainz to get a track's meta data. I want to get the track's album's mbid. I am doing the following lookup using ISRC code.
https://musicbrainz.org/ws/2/isrc/USRC11600201?fmt=json
But in response I don't get any metadata related to the album of the track. I get the following response:
{
"isrc": "USRC11600201",
"recordings": [
{
"disambiguation": "single remix",
"title": "Cheap Thrills",
"id": "92e27a47-3546-4bc2-a9f7-b19e43d7a531",
"length": 223000,
"video": false
},
{
"length": 218540,
"video": false,
"title": "Cheap Thrills",
"disambiguation": "",
"id": "5845e975-33b4-4b0d-8e74-8f57d128b3d1"
}
]
}
I have tried various combinations of the "inc" sub query parameter as well but nothing works. Please help me out. I am really stuck at this.
Using inc=releases in the URL parameters should be enough to get you the information that you want. However, it seems like there's a bug with MusicBrainz's JSON web service (which is still officially in beta), as you can see in the difference between the XML and JSON end points' output:
https://musicbrainz.org/ws/2/isrc/USRC11600201?inc=releases&fmt=json (JSON) vs. https://musicbrainz.org/ws/2/isrc/USRC11600201?inc=releases (XML).
One obvious solution/work-around here would be to switch to using the more mature XML endpoint. If that is not an option, you can use the Recording MBIDs given in the JSON output to look up releases associated with those Recordings, e.g., https://musicbrainz.org/ws/2/recording/5845e975-33b4-4b0d-8e74-8f57d128b3d1?inc=releases&fmt=json (note that inc=releases is also needed here to get the information about the releases, and it actually works when looking up recordings).
So to get the details of the album of a track when I have the ISRC of the track, we need to do the following get request:
https://musicbrainz.org/ws/2/isrc/GBUM71604605?inc=releases
It will give a response in xml. The xml api is more stable click for more details on this
As I need the response in json, we can use a library like xml to json and vice-versa library
As much as I have seen the xml response from the MusicBrainz api is more accurate and gives a lot of information.
I'm trying to user the contains filter on a /users query, like this for example:
https://graph.microsoft.com/v1.0/users?$filter=contains(displayName, 'Garth')
However, this results in a BadRequest response saying "An unknown function with name 'contains' was found. This may also be a key lookup on a navigation property, which is not allowed."
According to the OData 4.0 specs, the contains filter should be available though. Is there a way to use a contains filter on a list of users?
The contains function is not available for users. startsWith is available though.
e.g. https://graph.microsoft.com/v1.0/users?$filter=startswith(displayName,'Garth').
Additionally you can try the people API (this is only available on /beta). This supports $search AND will do fuzzy and phonetic matching.
https://graph.microsoft.com/beta/me/people?$search=Garth
$search can replace $contains
for example to show all the users that their names may contain the string "sa"
https://graph.microsoft.com/v1.0/users?$count=true&$search="givenName:sa"
"value": [
{....
"givenName": "Sammy",
.....
},
{
.....
"givenName": "Sabrina",
.......
},
.....