spo site set --url https://contoso.sharepoint.com/sites/sales --shareByLinkEnabled true
As it is possible to set ShareByEmailEnabled it would be great if we could set ShareByLinkEnabled as well.
ShareByEmailEnabled : true
ShareByLinkEnabled : true
Should be work the same as
spo site set --url https://contoso.sharepoint.com/sites/sales --shareByEmailEnabled true
Great suggestion! Thank you! Would you like to contribute this addition yourself? 馃檪
Thanks for your feedback, unfortunately I have not the skills to do so myself. Sorry for that!
@miscs totally not a problem and you've helped already bringing this to our attention. Thank you! 馃憦
@waldekmastykarz / @garrytrinder - Can I take a stab at this issue?
Absolutely @arjunumenon it鈥檚 all yours 馃憤馃徎
Thank you for your help 鉂わ笍
@garrytrinder / @waldekmastykarz I had been building the script for enhancing the commandspo site set for shareByLinkEnabledand now I am in a position where your valuable comments / suggestion would be of a great benefit.
Unlike ShareByEmailEnabledcommand, I don't think there is a shared Properties for for shareByLinkEnabled which we could leverage of
Since that being the case we may have to extend the command using the Tenant REST API for configuring the link settings for the Site, Is my understanding correct over? Pardon me If that is not the case
If my understanding is correct, do you think it make sense to extend the command with new parameter something like linkSharingTypesimilar to what PnP PowerShell follows for -sharing parameter.
Thanks for reaching out @arjunumenon 馃憤馃徎
I've looked at the output of the spo site get command on my developer tenant and can see that there is a property called ShareByLinkEnabled returned with a boolean value.

You should be able to push a new SetProperty element into the request payload for the ShareByLinkEnabled property, in a similar way to the existing ShareByEmailEnabled implementation shown below to set the value.
Have you found that the above is not the case?
You should be able to push a new SetProperty element into the request payload for the ShareByLinkEnabled property, in a similar way to the existing ShareByEmailEnabled implementation shown below to set the value.
if (typeof args.options.shareByEmailEnabled === 'string') {
payload.push(<SetProperty Id="${propertyId++}" ObjectPathId="5" Name="ShareByEmailEnabled"><Parameter Type="Boolean">${args.options.shareByEmailEnabled === 'true'}</Parameter></SetProperty>);
}
Thanks @garrytrinder for the quick response and direction. Though we get the property ShareByLinkEnabledin the GET call, we are unable to POST the property value when we set it via the REST using Shared Properties like you mentioned.
When we do that, I am getting the error below
Field or property \"ShareByLinkEnabled\" does not exist.
I had tried,
Making the REST call with the new property via Postman

Adding new parameter in the Office 365 CLI code base following the pattern you had recommended,

Attaching the debug screen of O365 CLI execution below so that you get a better idea on that.

Both are fetching the error Field or property \"ShareByLinkEnabled\" does not exist.. Based on that, I am assuming it doesn't allow you to set the property in that way.
I had also made another test case by making a REST call as a combination with the field ShareByEmailEnabled to make sure there are no dependency on that. Even the same error mentioned above.
Pardon me If I am not following the right approach / path. Any advise would be helpful.
Interesting, thank you for sharing your analysis.
Having looked at the docs, it appears that is designed to be a read only property as you have found.
https://docs.microsoft.com/en-us/previous-versions/office/sharepoint-server/jj862561(v=office.15)
As you mentioned, it would appear that the way to change this property is to change the SharingCapabilty property to one of the following valid options.
Source: https://docs.microsoft.com/en-us/previous-versions/office/sharepoint-csom/dn174825(v=office.15)
Thanks @garrytrinder for confirming my analysis. Thanks for sharing the documentation which gives me the right direction.
Based on your suggestion , for tackling this case, I think it makes more sense to have a new parameter SharingCapabiltyexpecting above enum values.
For doing that, do you think it make sense to have a new issue created with updated specs? Since I am relatively new to Contribution, I am not sure about the approach in these kind of scenarios. Your valuable suggestion is appreciated.
do you think it make sense to have a new issue created with updated specs
Absolutely, I've raised a new issue which references this issue, for the work to take place against.
Closing this issue following above investigation.