Add FilterRestrictions annotation transform to managedDevice entity type

[Egor Sidorenko (esidorenko-sl)]

Fixes #1193

microsoft.graph.managedDevice carries a description saying that $filter is only supported on some of its properties, but it has no FilterRestrictions annotation. With the annotation missing, Filterable defaults to true and the metadata tells every generated client that the whole collection can be filtered.

This adds the annotation, following the same approach as #227 for directorySetting.

What the change does

transforms/csdl/preprocess_csdl.xsl gets a new named template ManagedDeviceFilterRestrictionsTemplate that emits Filterable true plus a NonFilterableProperties collection, and two call sites mirroring the directorySetting ones. One handles the case where Annotations Target="microsoft.graph.managedDevice" already exists, which is what happens in both v1.0 and beta today, and the other creates the element if it is ever absent.

I did not reuse the existing FilterRestrictionsTemplate because it only emits the Filterable flag and there is no way to pass it a property list.

How the property list was built

I took the list from the metadata itself rather than from the API docs. A property counts as filterable if its own Core.V1.Description mentions $filter, which is exactly the rule the entity description states.

v1.0 has 55 properties, 20 of them filterable. Beta has 83 properties, 22 filterable, the two extra ones being deviceType and ownerType. The 35 properties listed in NonFilterableProperties are the ones that are not filterable in either version, so the same annotation is correct for v1.0 and beta. deviceType and ownerType are deliberately left out for that reason.

For reference, the 20 properties documented as filterable in v1.0 are azureADDeviceId, complianceGracePeriodExpirationDateTime, complianceState, deviceCategoryDisplayName, deviceName, emailAddress, enrolledDateTime, exchangeAccessState, imei, jailBroken, lastSyncDateTime, managementAgent, managementState, manufacturer, model, operatingSystem, osVersion, phoneNumber, serialNumber and userPrincipalName.

Testing

I added a type level Annotations element for managedDevice to preprocess_csdl_test_input.xml so the test exercises the same path that runs against the real schema, then regenerated preprocess_csdl_test_output.xml with transform.ps1. The output keeps the existing description and appends the new annotation with all 35 property paths. No other part of the output changed.

One note on the directorySetting template I copied from: it sets an attribute after copying child nodes, which XSLT ignores at that point. I left that out of the new template since @*|node() already copies the target attribute.

Happy to adjust the property list, or to redo this through additions/main.tsp instead if you would rather have new capability annotations go that route.

[Egor Sidorenko (esidorenko-sl)]

@microsoft-github-policy-service agree

[Egor Sidorenko (esidorenko-sl)]

I got access to a tenant with Intune and checked what the service actually does. It rejects the undocumented properties outright rather than ignoring them, which lines up with the annotation being the missing piece.

Requests against /v1.0/deviceManagement/managedDevices:

$filter	Documented as filterable	Result
deviceName eq '...'	yes	200
model eq '...'	yes	200
userId eq '...'	no	400 Unsupported parameter found in query
wiFiMacAddress eq '...'	no	400 Unsupported parameter found in query
notes eq '...'	no	400 Unsupported parameter found in query
id eq '...'	no	400

So the service knows exactly which properties can be filtered and says so at request parse time, before it looks at any data. The tenant I used has no enrolled devices, which does not matter for the 400 cases since the query never gets that far.

This is the same behaviour that #225 described for directorySetting, where filtering also failed with a 400 and the fix was to add the annotation.