Microsoft-graph-docs: Allow to $filter with empty string and null

[vanta]

Currently, when I GET e.g. https://graph.microsoft.com/v1.0/users?$filter=surname+eq+'', wanting to filter users with empty surname I get an error:

{
    "error": {
        "code": "Request_UnsupportedQuery",
        "message": "Unsupported or invalid query filter clause specified for property 'surname' of resource 'User'.",
        "innerError": {
            "request-id": "19cdfa84-4527-4945-89a4-cff8f867c7aa",
            "date": "2016-04-06T06:49:13"
        }
    }
}

I cannot see any other way to filter for empty string values on http://www.odata.org/documentation/odata-version-2-0/uri-conventions/ I tried https://graph.microsoft.com/v1.0/users?$filter=surname+eq+null as well with same result.

[marych]

There is no way to filter the users collection for entities with surname equal to null or empty string. The value of the filter must be between 1 and 64 characters as documented here: https://msdn.microsoft.com/en-us/Library/Azure/Ad/Graph/api/entity-and-complex-type-reference#userentity

[vanta]

I realised that but my point is to change it... as there is no way to fetch rooms or equipment, this would we the only way to fetch them (filter by empty surname) without fetching all users and filter them by myself... How about givenname can it be empty as I cannot see this constraint for it?

[marych]

If users are used to represent rooms or equipment you could potentially name them with a specific prefix and filter with startsWith, e.g. https://graph.microsoft.com/v1.0/users?$filter=startswith(surname,'room-'). Due to limitations of the current implementation of the /users entity set we will not be able to support filtering for nulls any time soon. The same limitation applies to all user properties, including givenname.

[vanta]

It's not "users are used to represent rooms or equipment", it's how Graph API works. I created rooms as rooms in Office365, not as users. I don't have a control over how rooms will be named by other users, so I cannot assume anything.

How about introducing flag to distinguish regular users from rooms/equipment in Graph API response?

[marych]

The Office 365 rooms are not as such exposed via the Graph API or any other REST API. It is available via EWS though, see https://msdn.microsoft.com/en-us/library/office/dn643730(v=exchg.150).aspx, so you'd need to use that in order to reliably get the list of rooms. Office 365 creates users for all rooms, but there is no flag on those users that could be used to distinguish them from regular users. While by default the surname and givenName properties are not set for such users there is nothing preventing setting these properties later on, so filtering for null would not be reliable either. In particular, in my environment both those properties are set for all rooms and I can find room users with https://graph.microsoft.com/v1.0/users?$filter=givenname+eq+'Conf%20Room'. The best we can offer via Graph API is to have a naming convention that would allow simple filters like the one above.

[vanta]

Thanks for clarifying. I cannot use any convention as my product is used by multiple companies and they can have different conventions or even none. But I could tell them "please don't put a givenname" (as it's blank by default) and it should work in most cases. That's why i do filtering now on app side, but it's not optimal as I fetch aaaaaallll users to filter most of them out.

So out Outlook Online UI distinguish between users and rooms if there is no flag to distinguish them? Using EWS API underneath?

[marych]

Yes, I believe the Outlook UI uses EWS. http://stackoverflow.com/questions/34858409/office-365-rest-api-access-meeting-rooms-calendars suggests to take a look at the new FindMeetingTimes API. If that doesn't help you might consider making the givenName/surname room prefix configurable in your app so that it could work for companies with different naming conventions - until rooms get properly exposed via Graph API.

[vanta]

I don't have a problem with rooms availability/booking, once I know the user is actually a room I simply add them with attendance type of "resource" using Graph API and it works.
As I mentioned, my convention is now blank givenname/surname (as this is a default behaviour for rooms), but the problem for me can be performance as I need to fetch all users.

Is this lack of null filtering for surname (and givenname?) due to some OData limitations?

Any plans that it will be exposed?

[marych]

The lack of null filtering is due to the way users are indexed. We can't efficiently retrieve users with an indexed property unset. There are no plans to change that.

[vanta]

@marych Make sense, thank you for explanation.

But any plans to expose "room flag" in user entity via Graph API?

[marych]

No plans for adding a "room flag" on user. There should be a separate room entity type IMO. Over time all EWS functionality should become available via REST APIs, but there is no timeline for room related functionality.

[vanta]

@marych Any change here? I need to load resources from company that has 27k+ users, max number of users I can get at once is 999, so I need to execute ~30 API calls to get all users and filter out most of them (I use empty givenname field as indicator for being a resource). This is unreasonable...

[marych]

@VenkatAyyadevara-MSFT - are there any plans to expose rooms via REST API?

[EvertKors]

@marych
The outlook API just released it (https://blogs.msdn.microsoft.com/exchangedev/2017/06/30/announcing-new-rest-apis-in-beta-for-rooms-time-zones-and-languages/)

Will listing rooms be possible soon in the Microsoft Graph API?

[EvertKors]

@angelgolfer-ms @arunv-msft Can you please answer, this functionality is crucial in my program, i would really really really love to see this happen, otherwise i have to do some tricky workaround where i ask my end users what email addresses can be labeled as rooms.

[arunv-msft]

@EvertKors - We do have plans for exposing the same in the Graph API but it might take a few months. So I would recommend that you start with the Outlook API for now. Also, do let us know your feedback; the API is currently in beta and we are looking for inputs on how we can improve it.

[vanta]

@arunv-msft any update here?

[marych]

I see in the changelog (https://docs.microsoft.com/en-us/graph/changelog?view=graph-rest-beta) that the findRoomLists and findRooms APIs were added to MS Graph in September 2017.

[vanta]

And after almost 2 years it's still in Beta that should not be used on production.

APIs under the /beta version in Microsoft Graph are subject to change. Use of these APIs in production applications is not supported.

And I still need to fetch thousands of users, filter out these with givennames or surnames... sad.

[maxlund]

Still having this exact same problem, checking if givenName is null is unreliable as one of our clients accidentally set a room's givenName.. sad.

[twentytwokhz]

And after almost 2 years it's still in Beta that should not be used on production.

APIs under the /beta version in Microsoft Graph are subject to change. Use of these APIs in production applications is not supported.

And I still need to fetch thousands of users, filter out these with givennames or surnames... sad.

Indeed, extremely sad. It's 2020 and there still isn't a working version for user filtering.
I'm trying to filter users based on appRoleAssignment without any success:
https://graph.microsoft.com/beta/users?$expand=appRoleAssignments&$filter=appRoleAssignments/any(s: s/resourceId eq '')

What could possibly go wrong?
Anyone have any ideas why this fails with BadRequest/Invalid filter clause ? 😢

[Licantrop0]

@vanta Microsoft recently released in public preview new capabilities for directory objects that can be accessed by adding ConsistencyLevel = eventual header and $count=true in the querystring.
Here more info about the new features.

The query you are looking for is here.