Consider moving 'planner plan details get' to the beta endpoint to return more labels

Description

m365 planner plan details get only returns the first 6 categories and their label. Turns out this is a limitation of the Microsoft Graph v1 endpoint (undocumented) but easily testable by running the query in the graph explorer.

V1.0 endpoint

   "categoryDescriptions": {
        "category1": null,
        "category2": "Test",
        "category3": "Burple",
        "category4": null,
        "category5": null,
        "category6": null
    }

vs beta endpoint

 "categoryDescriptions": {
        "category1": null,
        "category2": "Test",
        "category3": "Burple",
        "category4": null,
        "category5": null,
        "category6": null,
        "category7": null,
        "category8": null,
        "category9": null,
        "category10": null,
        "category11": null,
        "category12": null,
        "category13": null,
        "category14": null,
        "category15": null,
        "category16": null,
        "category17": "Test123",
        "category18": null,
        "category19": null,
        "category20": null,
        "category21": null,
        "category22": null,
        "category23": "test 51",
        "category24": null,
        "category25": null
    },

Steps to reproduce

Run m365 planner plan details get on a plan with more then 6 categories.

Expected results

All categories to show up

Actual results

Not all categories show up

Diagnostics

N/a

CLI for Microsoft 365 version

v5.1.0-beta.ffd9bc8

nodejs version

v16.13.1

Operating system (environment)

Windows

Shell

PowerShell

cli doctor

N/a

Additional Info

No response

[appieschot]

This issue can be closed as in the latest iteration the planner details are updated with all categories in the v1 endpoint, so no need to upgrade to beta. Discussion still has meaning as we might want to introduce a --beta flag later on.

[waldekmastykarz]

If we’re to look at it case-by-case, then here I’d be more inclined to use the v1.0 endpoint with a --beta flag. Thinking back about #3037, exposing --beta there as well would be better than issuing two separate calls. The challenge with adding --beta to the CLI is how we build and execute requests. In the current architecture, it literally means upgrading all commands which isn’t trivial. I’m thinking about another approach that we could potentially use. It would still require full re-architecture of the CLI, but I hope that it would give us a better way forward to accommodate such changes in the future.

If this is something you need urgently, the least intrusive way would be to add a --beta option in the command itself and adjust the URL of the call that we do. Should do a bigger rewrite in the future, it wouldn’t affect the options that are available to our users.