Applications `tags` unexpectedly changed from `applications.Actions` to `applications.application.Actions`

[jackofallops]

This seems to have occurred in the last few weeks, affecting all yaml specs.

-        - applications.Actions
+        - applications.application.Actions

This seems to be a typo?

[jackofallops]

bump - Is someone available to triage and respond to this? This apparent breaking change is blocking feature adoption and development in the Terraform AzureAD provider.

[baywet]

Sorry for the delay, we're not triaging issues on this repository.

I believe the root cause of the updates here are conversion library issues below and the related pull requests that were made to unblock PowerShell module mapping by updating operation ids. https://github.com/microsoft/OpenAPI.NET.OData/issues/585 https://github.com/microsoft/OpenAPI.NET.OData/issues/640

maybe you can elaborate how the changes here are causing an issue for you as changing them back may cause a problem for the PowerShell folks? Also looping in @irvinesunday and @timayabi2020 who originally implemented the change to unlock PowerShell

[jackofallops]

Thanks for the reply @baywet.

Our ingestion of the data expects a 2-part path for the tags, as seems to be the standard for every other tag in the spec. I can understand the desire to not regress, but the effective tag outcome noted above doesn't read as correct from this code: https://github.com/microsoft/OpenAPI.NET.OData/pull/641/files#diff-f916e1889920af4d79364a0dce97a70fd94ef53c8a4dff4e40664c59d9b2a643R176-R183 Rather than just appending .Actions in this case, we're seeing a tag that already had the suffix (applications.Actions) in the tag having an additional .application inserted, thus becoming applications.application.Actions? This feels like an unintended outcome for these tags?

[baywet]

I believe this was done to differentiate between list operations GET .../applications and read operations GET .../applications/app-id, and fix issues at the PowerShell filtering level.

[nathan-james-s]

bump - I believe this is still blocking https://github.com/hashicorp/pandora/pull/4707#issue-2901768872

[Jingwei-MS]

Hi team, do we have any updates regarding this issue? Please let me know if there is anything needed from our side.

[baywet]

Sorry, my last answer was incomplete. We're NOT going to change this back at this point, it would negatively impact PowerShell experiences. And our team has never made any "compatibility" guarantees regarding tags. At this stage, I'd suggest you use openAPI overlays and associated tooling (or some similar approach) to pre-process the description before feeding it into your tooling. Let me know if you have any questions or concerns.