microsoftgraph / microsoftgraph/msgraph-metadata
Non-supported paths are being generated in OpenAPI description
Nobody has claimed this yet.
- Dominant language
- XSLT
- Stars
- 166
- Forks
- 55
- Avg merge
- 16h 12m
- Merged PRs (30d)
- 14
Description
Endpoints like /groups/{group-id}/team/channels/{channel-id}/messages and all its nested resources, like /groups/{group-id}/team/channels/{channel-id}/messages/{message-id} or /groups/{group-id}/team/channels/{channel-id}/messages/{message-id}/hostedContents and so forth doesn't seem to be supported.
Even though they are being generated in the OpenAPI description:
Calling the API directly from teams/{teams-id}/channels/{channel-id}/messages (not groups) and other nested resources works just fine.
Because of that, we are also generating cmdlets for non-supported paths in our PowerShell module:
The only non-supported path under /teams/... I've noticed is teams/{teams-id}/channels/{channel-id}/messages/$count.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by comparing the generated OpenAPI paths for groups/{group-id}/team/channels/{channel-id}/messages with the supported teams/{teams-id}/channels/{channel-id}/messages paths. Trace those paths back through the metadata generation inputs and check how the PowerShell cmdlets are derived. Done means unsupported groups paths and the teams messages/$count path are no longer generated while supported paths remain.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- openapi
- Domain
- api, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100