microsoftgraph / microsoftgraph/msgraph-sdk-dotnet

[Client bug]: Pagelevel not available as a QueryParameter for Page/Pages requests

Open
#1,896 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Bug: metadata OpenApi
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:

  1. 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;
            });
  1. Uncomment the line enabling PageLevel query parameter. Observe that it results in compilation error.
  2. Attempt to apply workaround described in the issue description, with the use of RequestInformation.
  3. 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.