New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New command: list custom actions #19

Closed
waldekmastykarz opened this Issue Nov 11, 2017 · 12 comments

Comments

Projects
None yet
3 participants
@waldekmastykarz
Copy link
Member

waldekmastykarz commented Nov 11, 2017

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

This comment has been minimized.

Copy link
Collaborator

VelinGeorgiev commented Nov 29, 2017

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

@waldekmastykarz

This comment has been minimized.

Copy link
Member

waldekmastykarz commented Nov 30, 2017

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

This comment has been minimized.

Copy link
Collaborator

VelinGeorgiev commented Nov 30, 2017

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

This comment has been minimized.

Copy link
Member

waldekmastykarz commented Dec 1, 2017

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

This comment has been minimized.

Copy link
Collaborator

VelinGeorgiev commented Dec 1, 2017

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

This comment has been minimized.

Copy link

damsleth commented Dec 5, 2017

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

This comment has been minimized.

Copy link
Member

waldekmastykarz commented Dec 5, 2017

@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

This comment has been minimized.

Copy link

damsleth commented Dec 5, 2017

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

This comment has been minimized.

Copy link
Member

waldekmastykarz commented Dec 5, 2017

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

This comment has been minimized.

Copy link
Collaborator

VelinGeorgiev commented Dec 5, 2017

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

This comment has been minimized.

Copy link
Member

waldekmastykarz commented Dec 6, 2017

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

@damsleth

This comment has been minimized.

Copy link

damsleth commented Dec 6, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment