Cli-microsoft365: New command: list custom actions

[waldekmastykarz]

List all custom actions at the given scope.

• command: spo customaction list --url|-u <url> --scope|-s [scope]
• url of the site/web to retrieve custom actions for
• scope to retrieve custom actions for. Allowed values Site|Web|All. Default All
• requires connection to a SharePoint site

Decide which properties should be retrieved. Given that there can be many custom action defined at the given scope, this command should ideally include the minimum set of properties. To get all properties for the given custom action, users can run the spo customaction get command.

More information at https://msdn.microsoft.com/en-us/pnp_powershell/getpnpcustomaction

[VelinGeorgiev]

Hey @waldekmastykarz I can pick up that one. I am just wondering why it has a tag needs discussion?

[waldekmastykarz]

Awesome! We just need to decide which properties we want to show in the overview vs. which are visible only when getting a specific property using the spo customproperty get command. Any suggestions?

[VelinGeorgiev]

Hi @waldekmastykarz

If we follow the PnP PowerShell cmdlet, the output is

Name                   Location                          Scope Id
----                   --------                          ----- --
customaction1          Microsoft.SharePoint.StandardMenu Site  9f7ade35-0f8d-4c8a-82e1-5008ab42df55
customaction2          Microsoft.SharePoint.StandardMenu Site  42a1556e-69e5-481b-ad9c-8998d6a9a382

If we follow the spo customaction get the output, then for the table might look like:

Name, Location, Scope, Id, ClientSideComponentId, ClientSideComponentProperties
...

I think it is important to display the ClientSiteComponentId to verify if it is a client side specific specially for SharePoint Online because the amount of the SharePoint Framework development will increase over time.

Any other suggestions?

[waldekmastykarz]

Wouldn't that be too much to fit on a screen? Usually my terminal window isn't full screen so the table would wrap which would make it readable. This would especially be the case if we included ClientSideComponentProperties which can get pretty long.

What if we included Name, Location, Scope and Id in the list like you suggested first, and let everything else to be displayed in the customaction get command? Would that work or would we miss important details?

[VelinGeorgiev]

I am absolutely fine with that, that output is similar to the PnP PowerShell so would bring same experience to someone familiar with the cmdlets.

Let's do it :)

[damsleth]

How about an optional --verbose switch (or --details, as covered in #93 ), to list additional properties like ClientSideComponentProperties? Then we'd avoid having to use two commands to get additional properties. Also --verbose is pretty common in the npm ecosystem.

[waldekmastykarz]

@damsleth --verbose is already used for logging across the whole CLI, so if we were to do this, --details would be a better choice.

With regards to retrieving details: would you like to get details for all custom actions, even if things like ClientSideComponentProperties might apply only to a few of them? What properties would you include in the detailed view?

[damsleth]

Good point, --details makes more sense.
I prefer verbosity over brevity, so listing out all props that aren't potentially very long is fine by me.
i.e. exclude ClientSideComponentProperties, CommandUIExtension, ScriptBlock and the Rights object (so we don't have to iterate that as well).
I think Scope is also irrelevant since you specify it in the --scope switch.

Also, I see that the --debug switch gives me "everything but the kitchen sink", so that covers the "_give me all the properties_" use case.

Personally i think omitting null-valued properties from the results is a good idea too, but others might have different opinions.

[waldekmastykarz]

What about readability: all this would be displayed in a terminal window. Currently, output of list-commands is displayed as a table, where each item is a row and each property a column. Unless you run terminal full-screen and you're using a big monitor, there is no chance all of that would fit on the screen. How would you display it? This of course wouldn't be an issue if you chose --output json.

[VelinGeorgiev]

Initially my thoughts were to have 5+ columns as well, but now I would suggest to keep it simple at that early stage. --details adds more logic and skip of the null valued properties also would add even more logic in the command. I would prefer, we focus on the commands quantity over prettifying the output suggested by @andrewconnell.

I can implement it as you wish and it is not a problem, I would rather prefer to see similar output as what we have on the PnP powershell command (small table) because it might be hard to read in a 800x600 console if we go with 5+ columns. Then we can very quickly execute spo customaction get --id for the action we are interested in to get more details.

[waldekmastykarz]

@VelinGeorgiev agreed. Let's continue with the initial set and revisit in the future if still relevant.

[damsleth]

Following the PnP PowerShell cmdlet pattern with a table layout I agree it's best to keep the # of columns to a minimum. The (pretty neat, actually) --debug switch really covers all verbosity requirements.