Cli-microsoft365: Add 'spo homepage' command ?

[Laul0]

Summary

I found only one way to define a page as HomePage spo page set.
I didn't find:

• a cmdlet "dedied" to define a page as home page: spo homepage set --webUrl [...] --page [/sitepages|pages/mycustomhomepage.aspx]
• a cmdlet to retrieve/get the current home page: spo homepage get --webUrl

Why? Because, if the home page is not home.aspx how can you retrieve the home page by script? (maybe with spo web get?)

The main idea is to facilitate the home page management by dedied cmdlet?

What do you think about this cmdlet? If you agree with this idea, I'll write a properly the specs of this issue ;)

[waldekmastykarz]

Yes, we don't have support for setting the welcome page of a classic site at this moment. Rather than doing it through the page, I'd suggest extending the spo web set command with an additional option named --welcomePage where you can specify the URL of the page. How does that sound?

[Laul0]

And for get the home page url?

[waldekmastykarz]

Is there a way to extend the spo web get command to include it?

[Laul0]

A sort of option that allow you to return only the home page url you mean? (I didn't check yet if this information is present to the current output)

[waldekmastykarz]

Either that or to include the welcome page URL in the set of returned properties. If I'm not mistaken it's a property of SPWeb but I'm not sure if it's exposed through the client OM on Web or not.

[Laul0]

Hi @waldekmastykarz,

I tried to get the welcome page from the current command spo web get and you can found at the last row:

WelcomePage                                         : SitePages/Home.aspx

And I tried to set welcomePage from rest api and it works but the property can be only set from RootFolder endpoint.
With this information in mind, how do you think we should implement the set --welcomePage?
From the current spo web set and if the parameter welcomePage is defined we add a second request or it's preferable to create a new command?

[waldekmastykarz]

I'd opt for extending spo web set and handling the RootFolder nuance internally without bothering the user with it.

[Laul0]

By the way, I thought about the "get" option... That could have sense to add for a command get a parameter that look like --value?

Examples:

spo web get --webUrl https://mysp.sharepoint.com/sites/project-x --value 'WelcomePage'

spo web get --webUrl https://mysp.sharepoint.com/sites/project-x --value 'Title'

This behavior could be add progressively to the other commands... If I took as example the Starter Kit that you had create the provisioning script based on Office365-CLI, you have to use jq to extract the 'Id' of list... If you had this option with spo list get you could have used this command:

spo list get --webUrl $portalUrl --title 'Site Pages' --value 'Id'

I thought to used parameter like --value to not worry about the schema of the object... like that, it's generic.

Could it make it sense?

[waldekmastykarz]

Is the use case here to avoid requiring jq for things like retrieving a specific property? It might be interesting to investigate the need for this with CLI's users.

While I like the simplicity, I have a few thoughts about it:

• I'd prefer to use select instead of value as it more clearly reflects what's happening behind the scenes and maps to a concept people already know
• select typically allows selecting multiple properties, so if we followed it consistently with the API, the result would be that even for a single property you'd get {"id": "abc"}, instead or just abc unless we did some output manipulation which could easily get confusing
• if we introduced select, would the expectation be that we introduced other OData properties such as filter as well? Nothing against that per se, just trying to understand the reasoning behind it

In your proposal, you mention to introduce value to not have to worry about the schema of the object. Why would you worry about the schema? No matter if you use value or jq, you need to know that there is a property named Id in order to select it, so not quite sure what the difference is other than not needing to have jq and know its syntax.

[Laul0]

Yes, it is the idea... If some users are not familiar with jq, this solution could make sense for them and save them time?

I understand the select choice and the purpose. It's a little bit more advanced than my idea. I thought kept simple by retrieving only one value. Why? Because, in lot of use case, you just need Id, title or whatever (ex: welcomePage) and not the entire object. If you need more, jq still the best way.

If you return an JSON object with select that means you have to use jq to work/manipulate this object in your script, isn't it? So, in this case, you don't need select? Or, what you earn by using select?

Yes, I just wanted precise that the object schema should not be an obstacle. Your explanation makes me think that we on the same wavelength 😉

[waldekmastykarz]

I think we have a common understanding of what you're proposing. The benefit of using select would be alignment with an existing concept and minimizing the amount of data that's sent over the wire. It wouldn't address your specific use case though. How about we create a separate issue with the proposal for value as you mentioned it (select single property and return its value as plain text) and see what the interest for it would be?

[Laul0]

Yes, we can do that, absolutely!
Create an issue that look like a question? Did you already do that on your repo?

[waldekmastykarz]

Well, not really a question, but a spec that we could directly implemented if there is sufficient interest.

[Laul0]

Ok

[garrytrinder]

As we have implemented JMESPath querying since this issue was raised, you can now return the WelcomePage property using the below approach.

o365 spo web get --webUrl https://contoso.sharepoint.com --query "WelcomePage" -o json

A new issue has been raised to track the work required to extend the spo site set command with a spec and additional information, therefore I will close this issue.