Expected behavior
GET /v1.0/solutions/bookingBusinesses/{bookingBusiness-id}/services/{bookingService-id}
When calling this endpoint I want to receive data about services of a bookingBusiness as Object (BookingService) or List.
Actual behavior
Calls on this endpoint throws: java.lang.NumberFormatException: JSON forbids NaN and infinities: NaN
After some researches, I found out that the API is giving services back with defaultLocation.coordinates object with every field as NaN.
On the delegated auth, all coordinates fields are returned as null values.
"defaultLocation": {
"displayName": "",
"locationEmailAddress": "",
"locationUri": "",
"locationType": "default",
"uniqueId": null,
"uniqueIdType": null,
"address": {
"street": "",
"city": "",
"state": "",
"countryOrRegion": "",
"postalCode": ""
},
"coordinates": {
"altitude": "NaN",
"latitude": "NaN",
"longitude": "NaN",
"accuracy": "NaN",
"altitudeAccuracy": "NaN"
}
}
msgraph 5.46.0 maven repo
I search on the services GUI where I can remove this coordinates object, because we don't want to use it but I didn't found anything.
I tried to update the service through the API with nulls or doubles but the outcome in the SDK call is the same, only NaN comes.
Related
Using the Microsoft Graph API (v1.0) sites/{site-id}/lists/{list-id}/items end-point to try and find any new documents that have had a Compliance Tag applied. In the fields I see _ComplianceTagWrittenTime but when I supply that field into the filter I'm given 'field not recognized' error
Here is the list of fields
"fields": {
"#odata.etag": "\"etag\"",
"FileLeafRef": "Test.docx",
"id": "1",
"ContentType": "Document",
"Created": "2019-06-27T18:08:27Z",
"AuthorLookupId": "6",
"Modified": "2020-01-05T23:39:12Z",
"EditorLookupId": "6",
"_CheckinComment": "",
"LinkFilenameNoMenu": "Test.docx",
"LinkFilename": "Test.docx",
"DocIcon": "docx",
"FileSizeDisplay": "19243",
"ItemChildCount": "0",
"FolderChildCount": "0",
"_ComplianceFlags": "7",
"_ComplianceTag": "Short Record",
"_ComplianceTagWrittenTime": "2020-11-02T19:41:16Z",
"_ComplianceTagUserId": "6",
"_IsRecord": "7",
"_CommentCount": "",
"_LikeCount": "",
"_DisplayName": "",
"Edit": "0",
"_UIVersionString": "6.0",
"ParentVersionStringLookupId": "1",
"ParentLeafNameLookupId": "1"
}
This call works https://graph.microsoft.com/v1.0/sites/{site-id}/lists/{list-id}/items?expand=fields&filter=fields/Modified gt '2019-01-05T23:39:12Z'
but this one https://graph.microsoft.com/v1.0/sites/{site-id}/lists/{list-id}/items?expand=fields&filter=fields/_ComplianceTagWrittenTime gt '2019-01-05T23:39:12Z'
returns
{
"error": {
"code": "invalidRequest",
"message": "A provided field name is not recognized",
"innerError": {
"date": "2020-11-03T17:33:52",
"request-id": "{request-id}",
"client-request-id": "{client-id}"
}
}
}
No, you cannot filter the list items as of now as there is no support for it. Please upvote an already existing feature request in the Microsoft Graph Feedback forum.
Need help. We have 2 problems to extract custom fields data in MS-Booking by using Graph tool. We are near, but some records and/or data are sometimes missing when it wrong ...
On the first following command/request :
https://graph.microsoft.com/beta/bookingBusinesses/pouvtech#cegeptroisrivieres.onmicrosoft.com/appointments
PROBLEM : A lot of customer and appointments data are missing. Most of them are empty like the result below ...
{ "#odata.context": "https://graph.microsoft.com/beta/$metadata#bookingBusinesses('pouvtech%40cegeptroisrivieres.onmicrosoft.com')/appointments", "value": [ { "id": "AAMkADY2MjA3OGM3LTYwOWUtNGU5NS04YzAxLTE5NTk5MzJhN2I3OQBGAAAAAABCDbBYqWVtR5zSlJwdYN2dBwB4ZfrSVkupTZ_RUHowUU-UAAAAAAENAAB4ZfrSVkupTZ_RUHowUU-UAAALosc9AAA=", "selfServiceAppointmentId": "7e9e8039-2fe1-4369-9107-42f772503915", "additionalInformation": "<html>\r\n<head>\r\n<meta name=\"Generator\" content=\"Microsoft Exchange Server\">\r\n<!-- converted from html -->\r\n<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>\r\n</head>\r\n<body>\r\n<div>\r\n<div>\r\n<div>\r\n", "isLocationOnline": false, "onlineMeetingUrl": null, "customerId": null, "customerName": null, "customerEmailAddress": null, "customerPhone": null, "customerNotes": null, "serviceId": "b0da8ff4-aa62-4b04-ab6e-39ba3072ee4a", "serviceName": "Techniques de soins infirmiers", "duration": "PT45M", "preBuffer": "PT0S", "postBuffer": "PT0S", "priceType": "undefined", "price": 0, "serviceNotes": null, "optOutOfCustomerEmail": false, "staffMemberIds": [ "52637fe9-a068-4da1-aeed-a08cfc3b105f" ], "invoiceAmount": 0, "invoiceId": null, "invoiceStatus": "draft", "invoiceUrl": null, "invoiceDate": null, "customerLocation": { "displayName": "", "locationEmailAddress": null, "locationUri": "", "locationType": null, "uniqueId": null, "uniqueIdType": null, "address": { "type": "home", "postOfficeBox": "", "street": "", "city": "", "state": "", "countryOrRegion": "", "postalCode": "" }, "coordinates": { "altitude": null, "latitude": null, "longitude": null, "accuracy": null, "altitudeAccuracy": null } }, "start": { "dateTime": "2020-11-04T17:30:00-05:00", "timeZone": "America/New_York" }, "end": { "dateTime": "2020-11-04T18:15:00-05:00", "timeZone": "America/New_York" }, "serviceLocation": { "displayName": "En ligne", "locationEmailAddress": null, "locationUri": "", "locationType": null, "uniqueId": null, "uniqueIdType": null, "address": { "type": "home", "postOfficeBox": "", "street": "", "city": "", "state": "", "countryOrRegion": "", "postalCode": "" }, "coordinates": { "altitude": null, "latitude": null, "longitude": null, "accuracy": null, "altitudeAccuracy": null } }, "reminders": [] },
On the second following command/request :
https://graph.microsoft.com/beta/users/pouvtech#cegeptroisrivieres.onmicrosoft.com/events/AAMkADY2MjA3OGM3LTYwOWUtNGU5NS04YzAxLTE5NTk5MzJhN2I3OQBGAAAAAABCDbBYqWVtR5zSlJwdYN2dBwB4ZfrSVkupTZ_RUHowUU-UAAAAAAENAAB4ZfrSVkupTZ_RUHowUU-UAAAOTblRAAA=?$expand=singleValueExtendedProperties($filter%3Did eq 'Binary {ccb88e73-951a-4b10-bb49-e6628b8d8494} Name BookingItemAnsweredCustomQuestions')
PROBLEM : Custom fields data are sometimes missing because customer/appointments ID are missing like seen above. So, most of custom fields data are missing. We obtained 2 results on more than 100 appointments.
Can you help us ?
I believe this because singleValueExtendedProperties only works with 1-1 appointments in MS Bookings. I think you have multiple slots enabled in which case it only brings back the custom fields for the first slot in the booking. I have had the same issue and currently there is no work around I know of.
We are trying to call this MS Graph endpoint:
https://graph.microsoft.com/v1.0/users/delta?$deltatoken=<DELTA_TOKEN>&$select=id,displayName,givenName,surname,employeeId,accountEnabled,assignedLicenses,assignedPlans,licenseAssignmentStates,usageLocation,userPrincipalName,userType,businessPhones,mail,mailNickname,mobilePhone,proxyAddresses,streetAddress,city,country,companyName,department,jobTitle,officeLocation,postalCode,state,isResourceAccount,createdDateTime,deletedDateTime,lastPasswordChangeDateTime,onPremisesLastSyncDateTime,onPremisesDistinguishedName,onPremisesDomainName,onPremisesImmutableId,onPremisesSamAccountName,onPremisesSecurityIdentifier,onPremisesSyncEnabled,onPremisesUserPrincipalName
This is what we get:
"value": [
{
"displayName": "Jozef Surname",
"givenName": "Jozef",
"surname": "Surname",
"userPrincipalName": "jozef.surname#company.com",
"mail": "jozef.surname#company.com",
"id": "048...3d-eaf2-4199-8e88-9cd6...2091b"
},
{
"displayName": null,
"givenName": null,
"surname": null,
"userPrincipalName": null,
"mail": null,
"id": "ae...ecf-8ae8-4666-b158-93...c799c00"
},
{
"displayName": null,
"givenName": null,
"surname": null,
"userPrincipalName": null,
"mail": null,
"id": "33...d09-81a9-4304-833d-71...92f4b6a"
},
The question is, why are we getting records with null fields? We would expect records like the first one in above example.
When we query for some empty record (record with nulls) (https://graph.microsoft.com/v1.0/users/ae...ecf-8ae8-4666-b158-93...c799c00), we get this:
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#users/$entity",
"businessPhones": [],
"displayName": "Zuzana Surname4",
"givenName": "Zuzana",
"jobTitle": null,
"mail": "zuzana.surname4#company.com",
"mobilePhone": null,
"officeLocation": null,
"preferredLanguage": null,
"surname": "Surname4",
"userPrincipalName": "zuzana.surname4#company.com",
"id": "ae...ecf-8ae8-4666-b158-93...c799c00"
}
It’s an existing user. We just don’t know why it’s returned with null fields when we call /users/delta with deltaToken?
We would expect a response like this one (no “empty” records):
"value": [
{
"displayName": "Jozef Surname",
"givenName": "Jozef",
"surname": "Surname",
"userPrincipalName": "jozef.surname#company.com",
"mail": "jozef.surname#company.com",
"id": "04...33d-eaf2-4199-8e88-9c...b82091b"
},
{
"displayName": "Nick Surname2",
"givenName": "Nick",
"surname": "Surname2",
"userPrincipalName": "nick.surname2#company.com",
"mail": "nick.surname2#company.com",
"id": "4f...faa-f1eb-462b-be31-e5...5860a25"
},
{
"displayName": "Jan Surname3",
"givenName": "Jan",
"surname": "Surname3",
"userPrincipalName": "jan.surname3#company.com",
"mail": "jan.surname3#company.com",
"id": "25...f04-dbec-4580-b35b-3a...262b38c"
},
Is this a bug in /users/delta with deltaToken or is it expected behavior?
Thanks for any help.
With the above behavior, it is not possible to differentiate between a property that has not changed and one that has changed to a null value.
By default, requests using a delta link or next link return the same properties as selected in the initial delta query in the following ways:
If the property has changed, return the property in the JSON
response.
If the property has been set to an empty value, return the property value as null.
If the property has not changed, return the value as null.
yes exactly it should work how the documentation says and it is working this way with other tenants. However we are getting the properties which have the value (like UPN) with null values in the reponse. According to the documentation it should come with the current value of the property or if value was never set the property shouldn't be part of the response at all. It's really weird behavior..
The other part of MS docs says:
By default, requests using a deltaLink or nextLink return the same properties as selected in the initial delta query in the following ways:
If the property has changed, the new value is included in the response. This includes properties being set to null value.
If the property has not changed, the old value is included in the response.
If the property has never been set before it will not be included in the response at all.
What is pretty inconsistent with the MS docs from the answer above.
The question is what will "$select" does if it is used for the property which was not supposed to be part of the response, based on the condition above.
We found two different behaviours creating an event using Outlook Desktop and Outlook Web (OWA).
Consider create an event A with Outlook Desktop and event B with Outlook Web (OWA) with two "rooms" (location).
Result of event created with Outlook Desktop:
"locations": [
{
"displayName": "Room 1; Room 2",
"locationType": "default",
"uniqueId": "Room 1; Room 2",
"uniqueIdType": "private"
}
],
Result of event created with Outlook Web OWA:
"locations": [
{
"displayName": "Room 1",
"locationType": "conferenceRoom",
"uniqueId": "room1#xxx.onmicrosoft.com",
"uniqueIdType": "directory",
"locationUri": "room1#xxx.onmicrosoft.com",
"address": {
"street": "",
"city": "",
"state": "",
"countryOrRegion": "",
"postalCode": ""
},
"coordinates": {}
},
{
"displayName": "Room 2",
"locationUri": "room2#xxx.onmicrosoft.com",
"locationType": "conferenceRoom",
"uniqueId": "room2#xxx.onmicrosoft.com",
"uniqueIdType": "directory",
"address": {
"street": "",
"city": "",
"state": "",
"countryOrRegion": "",
"postalCode": ""
},
"coordinates": {}
}
],
Why when the event is created with Outlook Desktop the "locations" field comes shorten? Is it a bug?
How to always get the full "locations" (like Outlook Web OWA result), no matter with what Outlook version?
Thank you.
The location resource will on return populated properties. So if the application that created the Event doesn't specify an address, coordinates, or locationUri, then the API won't return them.
I am getting user's timeline from an iOS app, with a big number of tweets being pulled from the API. I am using the statuses/user_timeline endpoint to get the data, however, as I'm on a mobile device and as I only need the tweet text only, I'd like to filter only the actual text data of the tweets. I've already set include_entities to no and trim_user to true, but even with entities and user data trimmed off, I'm still getting a lot of data that I don't need. Here is a sample tweet that I get from the endpoint:
{
"created_at": "Tue Nov 27 14:13:13 +0000 2012",
"id": 273429272209801200,
"id_str": "273429272209801217",
"text": "you could list #5ThingsIFindAttractive but you can actually find them on Facebook with Social Match on iPhone! http://t.co/zRr1ggbz",
"source": "web",
"truncated": false,
"in_reply_to_status_id": null,
"in_reply_to_status_id_str": null,
"in_reply_to_user_id": null,
"in_reply_to_user_id_str": null,
"in_reply_to_screen_name": null,
"user": {
"id": 62828168,
"id_str": "62828168"
},
"geo": null,
"coordinates": null,
"place": {
"id": "682c5a667856ef42",
"url": "http://api.twitter.com/1/geo/id/682c5a667856ef42.json",
"place_type": "country",
"name": "Turkey",
"full_name": "Turkey",
"country_code": "TR",
"country": "Turkey",
"bounding_box": {
"type": "Polygon",
"coordinates": [
[
[
25.663883,
35.817497
],
[
44.822762,
35.817497
],
[
44.822762,
42.109993
],
[
25.663883,
42.109993
]
]
]
},
"attributes": {}
},
"contributors": null,
"retweet_count": 0,
"favorited": false,
"retweeted": false,
"possibly_sensitive": false
}
The only thing I actually need is the text key of the dictionary. The rest is currently useless for my app. I'll be requesting LOTS of tweets like this. How can I send a request to just to pull of the text key of the tweets? Currently, this method is extremely inefficient.
You can't. The best you can do is set up a proxy which will request the data, strip it back, and then forward it to the mobile.
If it's any consolation, the JSON will be gzip'd and so should still be relatively small - so won't take too long to transfer or eat in to the user's data allowance.