Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolves operationId and tag names for OData cast paths #338

Merged
merged 25 commits into from
Mar 29, 2023

Conversation

irvinesunday
Copy link
Contributor

Fixes #324

This PR:

  • Renames the operationId and tag names for OData cast paths to conform with other no non-OData cast paths.

NB: The PR is currently in draft because:

  • The relevant Integration and unit tests haven't been updated yet. I will need to lock in any requested changes before updating these.
  • Complex properties and $count paths currently don't have tags generated for them. We need to agree on a format before these can be updated into this fix. The discussion can be found here.

@irvinesunday irvinesunday marked this pull request as draft February 1, 2023 09:51
@sonarqubecloud
Copy link

sonarqubecloud bot commented Feb 1, 2023

SonarCloud Quality Gate failed.    Quality Gate failed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 8 Code Smells

0.0% 0.0% Coverage
0.0% 0.0% Duplication

@irvinesunday
Copy link
Contributor Author

irvinesunday commented Feb 6, 2023

@baywet and @peombwa I might need some much-needed eyes on this draft PR before I proceed to add the tests :)

/// <param name="navigationSource">The <see cref="IEdmNavigationSource"/> of the target path.</param>
/// <param name="prefix">Identifier indicating whether it is a collection-valued non-indexed navigation property.</param>
/// <returns>The operation id name.</returns>
internal static string GenerateNavigationPropertyPathOperationId(ODataPath path, IEdmNavigationSource navigationSource, string prefix = null)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we standardize the naming convention of operationIds to what we have in DevX API - https://github.com/microsoftgraph/microsoft-graph-devx-api/blob/dev/OpenAPIService/PowershellFormatter.cs?
For example:

  • Remove hash suffix values from operationIds of function paths.
  • Add '_' to separate verb (action) in an operationId. This typically the last . or second . for OData cast paths.
  • PUT operations should have Set as the verb in an operationId {xxx}_Set{yyy}.

In PowerShell, we use operationIds to form command names.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See my comments at #324 (comment) on operationIds and tags for count and complex property paths.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we standardize the naming convention of operationIds to what we have in DevX API - https://github.com/microsoftgraph/microsoft-graph-devx-api/blob/dev/OpenAPIService/PowershellFormatter.cs? For example:

  • Remove hash suffix values from operationIds of function paths.
  • Add '_' to separate verb (action) in an operationId. This typically the last . or second . for OData cast paths.
  • PUT operations should have Set as the verb in an operationId {xxx}_Set{yyy}.

In PowerShell, we use operationIds to form command names.

There are other clients who rely on the operation ids, not sure it will be a good idea to handle that in this library. See this issue.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are also using AutoREST in the referenced issue - microsoftgraph/msgraph-metadata#289. Standardizing the operationIds here and ensuring uniqueness will have the net effect of fixing their issue.

To unblock this change, I've created an issue at #361 for us to discuss this further.

@irvinesunday irvinesunday marked this pull request as ready for review March 13, 2023 21:09
peombwa
peombwa previously approved these changes Mar 24, 2023
@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 5 Code Smells

92.8% 92.8% Coverage
0.0% 0.0% Duplication

@irvinesunday irvinesunday merged commit 7942102 into master Mar 29, 2023
@irvinesunday irvinesunday deleted the fix/is/odata-type-cast-opIds branch March 29, 2023 10:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

OData cast paths should follow the same naming convention for tags and operationIds as non-OData cast paths
2 participants