It would make sense to completely block custom scripts, but Microsoft will have to provide an updated API first because there are many capabilities that for some strange reason depends on custom scripts being enabled. Like writing to the property bag or adding a new menu item to the context/gear menu, both are often required but beats me why they are dependent upon custom scripts being enabled?
I think that SPFx can do all those things, though. I know it can access the property bag. Maybe the goal is to move these risky activities to the developers, who would package them up into SPFx.
That's a fair point! All Microsoft admins (regardless of product) should be comfortable with PowerShell. That being said, any time I can do something easier, I'll take it 🤣
There's a piece of the jigsaw missing from this story. What happens to applications that use scripts that run on a daily basis? What about Shargate if the migration takes more than a day?
You could add the "allow script" PS command to the beginning of your script. In terms of a "better" solution, especially when it comes to ShareGate and other popular apps, a better solution will be developed. There are better ways to solve the need for custom scripting. Custom scripting was a carry-over from the classic days, in my opinion.
This is actually bad news for those people who want to use custom scripts. THe modern script editor web part is no longer a viable web part. They've made the announcement that come november you can no longer change the configuration to prevent the toggle to be flipped back to blocked. So anything that relies on custom scripts you will need to have a powershell script running everyday to allow custom scripts for a given site. It's a UI change because people will need to do this ALL THE TIME for a given site.
What type of custom script are you running every day on a site? Just curious... I know there are better solutions. As another person commented, ShareGate will have to adapt as well.
Edit the solution itself - edit the manifest: "requiresCustomScript": false And then make a package "sppkg" and deploy the package to app catalog. Then the webpart you can add to the site where you did before allowed custom scripting. After several hours it is disabed, but the Script Editor still works - verified on my side.
