microsoftgraph / microsoftgraph/msgraph-sdk-dotnet
[Client bug]: Pagelevel not available as a QueryParameter for Page/Pages requests
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 789
- Forks
- 264
- Avg merge
- 15h 17m
- Merged PRs (30d)
- 3
Description
Describe the bug
In the Onenote Graph API spec page, there exists a way to show detailed metadata of a page, by using the pagelevel query parameter. This is clearly described in https://learn.microsoft.com/en-us/graph/onenote-get-content#page-entity. However, the current SDK implementation doesn't allow this query parameter to be set, and due to the template replacement that occurs, workarounds like
var requestInformation = _graphServiceClient.Users[user.Id]
.Onenote.Sections[section.Id].Pages.ToGetRequestInformation();
requestInformation.QueryParameters.Add("pagelevel", "true");
var result = await _graphServiceClient.RequestAdapter
.SendAsync<OnenotePageCollectionResponse>(requestInformation,
OnenotePageCollectionResponse.CreateFromDiscriminatorValue)
don't work either as the query parameters can't be forced in the request.
The issue gets fixed by adding the query parameter in the template and the Request model. I have tested and verified it locally using this branch, which applies it only to the Microsoft.Graph.Users.Item.Onenote.Sections.Item.Pages namespace objects for simplicity: https://github.com/dgounaris/msgraph-sdk-dotnet/tree/patch/pagelevel-onenote.
However if my understanding is correct, Kiota is used to update the API definitions, thus I'm afraid that opening a PR with this fix will get overwritten at a later point until Graph API correctly captures this query parameter. Let me know if this is not the case and a patch can be applied manually, I'd be happy to fix the rest of the occurences and publish the PR.
To Reproduce
Steps to reproduce the behavior:
- Try using the declarative SDK command for any of the page collection or page requests, for example:
var result = await _graphServiceClient.Users[user.Id]
.Onenote.Sections[section.Id].Pages.GetAsync(requestConfiguration =>
{
// requestConfiguration.QueryParameters.PageLevel = true;
});
- Uncomment the line enabling PageLevel query parameter. Observe that it results in compilation error.
- Attempt to apply workaround described in the issue description, with the use of RequestInformation.
- See that the pagelevel query param gets skipped.
Expected behavior
Pagelevel should be an allowed query parameter
Screenshots
If applicable, add screenshots to help explain your problem.
Client version
Provide the client version number from the NuGet package.
Desktop (please complete the following information):
- OS: Not relevant, this is backend usage
- Browser: Not relevant, this is backend usage
- Version Not relevant
Additional context
Add any other context about the problem here.
Contributor guide
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 OneNote Pages request template and Request model with the tested patch branch linked in the issue. Check the declarative Page/Pages request configuration and the RequestInformation workaround, then verify that pagelevel is accepted, retained, and no longer causes the documented compilation or request-generation failures.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- api
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100