Paths not generated for apis that return entity types with no navigation property but have base types with navigation properties

[timayabi2020]

A path is not generated for an api that returns an entity type with no navigation property but its base type has a navigation property.
To avoid such a translation error Odata-Openapi library should consider navigation properties of the base type. We have such an example on /users/{user-id}/insights/trending path being generated only on v1.0 but not beta.
v1.0 metadata

Here the path be generated because the entity type has a navigation property

beta metadata

Here, the entity type has no navigation property but the base type as shown below has navigation properties

However, the path won't be generated.

Using powershell Find-MgGraphCommand, we will have the below output when we try to find out if the paths have been generated for both v1.0 and beta version. i.e path was only generated for v1.0

[darrelmiller]

This seems to be related to #269

[irvinesunday]

The ask here is to expand to the navigation properties of the base type of the entity type targeted by a given containment navigation property if the said target entity type has no declared navigation properties.

1. Is this a feature we would want to enable for the above specific scenario?
2. Would we want to expand to all navigation properties declared in the target structured type and all base types?

@darrelmiller @baywet

[baywet]

if the said target entity type has no declared navigation properties

This makes me uneasy as it's an easy way to shipping breaking change. Week 1, the derived type doesn't have any nav props, so we expand the base type nav props on it. Week 2, a navigation property has been added to the derived type, we expand that but stop expanding the ones from the parent. This makes for a breaking change.

Would we want to expand to all navigation properties declared in the target structured type and all base types

I'd say no, since the base type doesn't have the nav prop from the child type, nothing guarantees the service will honour the request. And according to OData semantics, it shouldn't. As for expanding properties from the base type into the derived type, this is just going to create duplication and artificially inflate our SDKs.

Could/should we rely on OData type cast segments instead?

[irvinesunday]

In the provided example above, is this a possible workload error? If so, why not modify the entity type graph.itemInsights for the navigation property insights in beta to match the entity type in v1.0, graph.officeGraphInsights, using XSLT?

v1.0

beta

[baywet]

The iteminsights entity type doesn't declare anything else. To me it looks like a botched attempt at erasing the previous branding (Office Graph) without causing a breaking change on the API surface. But the rollout to v1 probably was blocked by our team or the API council since it'd be a binary breaking change.
The documentation history would support that
https://github.com/microsoftgraph/microsoft-graph-docs/commits/main/api-reference/beta/resources/iteminsights.md
https://github.com/microsoftgraph/microsoft-graph-docs/commits/main/api-reference/beta/resources/officegraphinsights.md

Maybe @elmakhmu or @simonhult can help understanding the context here? (both on vacations until January)

[elmakhmu]

Thanks for adding me to this discussion.
Indeed this change was done to exclude officeGraph mentioning from everywhere (including schema and documentation). We've done it because Office Graph concept was mixed up with Microsoft Graph and we've got a lot of customer escalations related to that.

The change was made a 2-3 years ago AFAIR, and ever since we released more dependencies from itemInsights, so it's absolutely impossible to return back to "OfficeGraph" concept.

What can we do on our side to make schema and API surface compliant in beta?

[baywet]

@elmakhmu Thanks for joining the conversation here. Since the renaming change never made it to v1 (because it'd have been a breaking change), and since the beta change doesn't contain anything meaningful, I'd suggest rolling back the change in beta.
The alternative would be to go through the 2 years deprecation lifecycle to push the breaking change in beta (probably by renaming the type or something similar, instead of having a specialized type that "contains nothing").

Either solution would reduce the confusion on the customers' side, and ensure your workload is compliant with beta to v1 releasing SLAs, as well as reduce maintenance burden on our side.
Thoughts?

[irvinesunday]

This has been resolved by this PR: #377