Project Online: SharePoint Custom Script control impact

In February 2024, Message Center post MC 714186 detailed changes to custom script settings in SharePoint Online. Although the MC post did not specifically mention Project Web App sites in Project Online, they are affected by these changes in several ways. There is a setting to re-enable this functionality, which we will discuss later, but common issues customers have reported include:

• Project Web App web parts are no longer listed as a web part category.
• The ability to save a site as a template is no longer available.
• Script Editor and Content Editor parts can no longer be added to pages (these are often used to add functionality to Project Web App)
• Custom fields added to a Project Details Page (PDP) are not ‘sticky’ – they appear to be added but disappear when you stop editing.
• Report of 3^{road name} Party applications that automate the above steps have also been reported.

Besides the last point, Nothing breaks or stops workingEven just using these features requires additional work to ‘unblock’ these scenarios. If you use a custom script today, for example a button set to publish all projects, it will still work regardless of the settings described here. These settings only apply to changes, for example if you need to edit the code behind the button.

Steps to re-enable the above features

Until November 2024, all unblocks will remain in effect until November 2024, if you run a single PowerShell command. After that period, you will need to unblock every 24 hours if you want to perform the listed actions, unless you run the script.

Tenant administrators can choose to run a new PowerShell command in SharePoint Management Shell version 16.0.24524.12000 or later after running Connect-SPOService.

memo: When implementing this, you need to understand the following: Security meaning.

Connect-SPOService -Url https://-admin.sharepoint.com

Set-SPOTenant -DelayDenyAddAndCustomizePagesEnforcement $True

Even if your administrator chooses to set this option, you will still need to follow these steps to make the bulleted changes at the top of this document. Implement DelayDenyAddAndCustomizePages Prevents settings from reverting after 24 hours. These steps require a SharePoint administrator to run a PowerShell script or change the settings in the SharePoint admin center. Note that PWA administrators are site collection administrators, but may not be SharePoint administrators.

Via PowerShellFor PWA sites, you need to run Connect-SPOService followed by:

Set-SPOSite -DenyAddAndCustomizePages 0

where This is a PWA site. Once done, you should be able to perform the options as usual. A simple check is to make sure that: Save your site as a template It will show up again in your site settings.

Through the SharePoint admin centerAdmins go to Sites, Active Sites, navigate/search for the site and click on the site name. In the window that opens, go to the Settings tab, you will see the Custom Scripts option, it says Blocked and under that there is an Edit option.

Clicking Edit will display an option to set the action to Allowed instead of Blocked, along with a warning text and a reminder that it will revert in 24 hours. This reminder will also appear if a script is running that prevents the reversion.

Clicking ‘Save’ will display additional warnings, links to the security impact document mentioned above, and a request to confirm the changes.

An additional column has now been added to the Active Sites list, exposing: Custom script Set up with a useful new filter that shows all sites that have custom scripts set up Allowed.

SharePoint administrators can also choose to revert changes via the UI or PowerShell after the change is complete, rather than relying on automatic reversion after 24 hours. That’s probably not a bad idea.

This change was introduced due to concerns about what custom scripts can do and the scenarios they affect that are not typically ‘everyday’ occurrences within PWAs. However, we understand that it requires intervention by SharePoint administrators and is more than a minor inconvenience. We’re still exploring what other options there are here, but it’s best to plan on involving a SharePoint administrator when doing these types of edits in the future. We use the term ‘custom script’ in this issue, but many of the blocked options may not actually look like they involve custom scripting. However, it’s more about what you ‘can’ do. For example, if you edit a PDP and add only Enterprise custom fields, no custom script will be added, but you can ‘add’ a script editor web part with script while editing. It’s more about making sure that conscious decisions are made about these things.

We are also working on a Learn.Microsoft.com article that will be out soon. We apologize for any confusion and lack of communication regarding this change, as we should have explicitly included Project Online in the message center post.

This does not apply to PWAs, but is for reference only.

One thing that is confusing is that the SharePoint Message Center post and subsequent articles start talking about the following section with a setting that allows users to run custom scripts on OneDrive and self-service created sites. Project Web App does not fall into this site category, so you do not need to enable this setting for the above scenario to work. The above steps are all that is needed. The settings page has also changed so that the prevention of personal sites is no longer changed. It might look like this:

Or here’s a more recent screenshot of the SharePoint Classic Settings section of the Custom Script. Either way, it doesn’t apply to Project Online sites.