Cli-microsoft365: New command: List available Microsoft Graph schema extensions

[waldekmastykarz]

Usage

graph schemaextension list [options]

Description

Get a list of schemaExtension objects created in the current tenant, that can be InDevelopment, Available, or Deprecated.

Options

Option|Description
------|-----------
--status,-s [status]|The status to filter on
--owner [owner]|The id of the owner to filter on
-p, --pageSize [pageSize]|Number of objects to return
-n, --pageNumber [pageNumber]|Page number to return if pageSize is specified (first page is indexed as value of 0)

Additional Information

pageNumber is specified as a 0-based index. A value of 2 returns the third page of items.

More information: https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/api/schemaextension_list

[wobba]

Would supporting odata $filter work? Easier than wrapping it with specific queries perhaps.

[waldekmastykarz]

@wobba in other CLI commands we usually grab all items in the collection which you can then process (sort, filter) through JSON output.
When using $filter, would you use it to find a single item or multiple items sharing a common value? Do you find yourself often using a specific value on which you filter?

[wobba]

@waldekmastykarz Good point - listing all seems what I've done so far - but then again, I wouldn't really go look for a schema which suits my need. I would create my own. Fetching all can take some time if the number grows to 1000's and beyond. Something to think about. Fetching based on status might be a thing though to avoid getting discarded ones.

[waldekmastykarz]

@wobba typing the exact $filter query is rather error prone, so if there are properties users frequently filter on, we could expose them as command options and build the $filter query ourselves in the command. Which ones would you suggest?

[wobba]

Filter on status, and filter on owner appid I think.

[ypcode]

Hi guys @waldekmastykarz @VelinGeorgiev

If the design discussion is clear enough ? which I think, can I take this one ?

[garrytrinder]

Hey @ypcode thanks for reaching out to take a look at this.

I think it would be wise to create a spec based on our new template so that we have clarity on what is to be built and the functionality the command will offer, this will help us a lot when we come to review the PR.

Do you fancy having a go at defining the spec?

[ypcode]

Hi @garrytrinder ,

Of course, based on the discussion above, I would propose:

• command graph schemaextension list --status|-s [status] --owner [owner] --pageSize|-p [pageSize] --pageNumber|-p [pageNumber]

Option|Description
------|-----------
--help|output usage information
--status,-s [status]|The status to filter on
--owner [owner]|The id of the owner to filter on
-o, --output [output]|Output type. json or text. Default text
-p, --pageSize [pageSize]|Number of items to return.
-n, --pageNumber [pageNumber]|Page number to return if pageSize is specified (first page is indexed as value of 0)
--verbose|Runs command with verbose logging
--debug|Runs command with debug logging

Remarks

pageNumber is specified as a 0-based index. A value of 2 returns the third page of items.

Comments

I made a few tests, and it looks like filtering is not supported for other properties...
Actually, it doesn't raise an error but the filters are not applied.

The command would follow up the @odata.nextLink for subsequent Graph calls to return the whole results array if paging options aren't specified. However, without any filter, the output could be quite big... Maybe either at least one filter or paging should be required

What do you think guys?

Oh and Merry Christmas to all ! :)

[waldekmastykarz]

Thanks for the spec @ypcode. Looks good. With regards to paging, what if we used a default pageSize of 10 and if you wanted to get all items, you'd use a separate flag --all and then we'd use the pageSize in our requests (or not if it doesn't add any value)?

[ypcode]

I think the spec is quite clear, I will be able to take it after mid-february, but feel free to assign if someone is available for it before that :)

[garrytrinder]

Thanks for the update @ypcode, I'll mark this as available to pick up.

[garrytrinder]

Updated the OP with the new spec in the new command template format as well as the Issue title.

@waldekmastykarz the command spec proposed is now consistent with similar commands that implement paging already in the CLI such as spo listitem list. I like the idea of the -all option you have proposed however I think that we should consider that as an enhancement to the base command should there be value in doing so.

[waldekmastykarz]

You're right @garrytrinder

[rabwill]

Hey @waldekmastykarz and @garrytrinder I’d like to give a shot at a command with paging. If Yannick is not already working on this I’d like to pick it up. Thanks

[waldekmastykarz]

All yours! 👏

[rabwill]

Ok folks, I have one doubt in this one, apologies if I sound amateur.

From the spec I can infer that if pageSize is provided, then we get items pageSize * (pageNumber+1) and pass the last pageSize items to the user.
Cause in this api as much as i tried, I could not skip to a batch like with SP apis.

[waldekmastykarz]

Wouldn't passing the values using OData's $top and $skip work?

[rabwill]

$skip has no effect on the schemaExtensions api. It respects only the $top when I check.

What we can do is get the @odata.nextlink from the result of the first api call (where we fetch all items pageSize*pageNumber , where pageNumber is non-zero and then make another call to @odata.nextlink.
If this sounds okay I can go ahead with it.

[waldekmastykarz]

Before we do this, let's check with the MS Graph team if this is intentional or a bug in the API. It would be good to understand why things are the way they are before deciding on a workaround. Would you mind submitting a question in the MS Graph docs and pinging Jeremy Thake?

[rabwill]

I had created an issue here https://github.com/microsoftgraph/microsoft-graph-docs/issues/7739#issue-599228875 and tagged Jeremy Thake. But seems like this is not the right place except if it is a documentation issue. So have opened an issue in stackoverflow and tagged microsoft-graph.
Will be keeping an eye out on this one.

https://stackoverflow.com/questions/61199327/skip-has-no-effect-on-the-end-point-to-list-schemaextensions-in-microsoft-graph

[waldekmastykarz]

Sorry for pointing you in the wrong direction @rabwill. Each time handles things differently and at times it's very much hit'n'miss to find the right channel for the particular team. Appreciate your effort following this 👏

[rabwill]

No problem at all ☺️

[rabwill]

To follow up with stackoverflow question , we have a reply form MSFT that all AAD resources work with skipTokens rather than skip. schemaExtensions come under the group resource type so makes sense.
As initially suggested , the first response gives us the url with skipToken which will be the endpoint we have to call in order to get the desired page.

[waldekmastykarz]

So in other words, we can't skip directly to the particular page and have to retrieve all data until that page first to obtain the correct skipToken, right?

[rabwill]

That’s the right way to put it. I am happy to give it a go.

[waldekmastykarz]

We could keep the original list of options and abstract this behavior away from users so that if they want to retrieve n-th page, we do that in the background presenting them with the data they need. Thank you for looking into it 👍

[rabwill]

Crazy week, will look into this in the next community day (coming week) folks.

[waldekmastykarz]

No problem. Thank you for the update! ❤️

[VelinGeorgiev]

Thank you Rabia @rabwill ! This is now merged to master.