Project Online: SharePoint Custom Script control impact

In February 2024, Message Center post MC 714186 detailed changes coming to Custom Script settings in SharePoint Online.  The MC post did not specifically call out Project Web App sites in Project Online, but it is impacted by these changes in a number of ways.  There are settings to re-enable these features which will be explained later, but the typical issues reported by customers are:

• Project Web App web parts are no longer listed as a web part Category
• Save site as template is no longer available
• Script Editor and Content Editor parts no longer available to add to a page (these are often used to add functionality to Project Web App)
• Custom Fields added to Project Detail Pages (PDPs) do not ‘stick’ and although it looks like you added them, they are not present when you stop editing
• Reports of 3^rd party applications that automate steps like those above, have also been reported

Apart from the last bullet point, nothing breaks or stops working, just the steps to use these features will require an additional action to ‘unblock’ these scenarios. If you use custom script today, maybe a button that is set to publish all your projects, then this will still work, regardless of the settings described here.  These settings only apply to changing things - for example if the code behind the button needed to be edited.

Steps to re-enable above features

Until November 2024 a single PowerShell command can be run which will ensure that any unblocking will last until November 2024.  After that time, and if you do not run that script, you will need to unblock for each 24-hour period that you want to carry out any of the listed actions.  

A tenant admin can choose to run a new PowerShell command in the SharePoint Management shell version 16.0.24524.12000 or later, after executing Connect-SPOService:

NOTE: When implementing this make sure you understand the security implications.

                Connect-SPOService -Url https://<tenantname>-admin.sharepoint.com

                Set-SPOTenant -DelayDenyAddAndCustomizePagesEnforcement $True

Even if the admin chooses to set this option, they will still need to proceed with the next steps to allow any of the changes bulleted at the top of this article to be carried out.  The DelayDenyAddAndCustomizePagesEnforcement  just avoids the setting getting revert after 24 hours.  These steps will require a SharePoint Administrator to either run a PowerShell script or make a setting change in the SharePoint Admin Center.  Be aware that the PWA admin, even though a site collection admin, may not be a SharePoint Admin.

Via PowerShell, for the PWA site they would need to run (after Connect-SPOService):

                Set-SPOSite <SiteURL> -DenyAddAndCustomizePages 0

where <SiteURL> is your PWA site.  Once complete, you should be able to carry out the options as usual.  A quick check is to see if Save site as a template is present again in Site Settings.

Via SharePoint Admin Center, the admin would navigate to Sites, Active Sites, browse/search for the site and click the site name.  In the pane that opens, navigating to the Settings tab will show an option for Custom scripts, which will say Blocked and have an option to Edit underneath.

Clicking Edit shows an option to set to Allowed rather than Blocked, along with some warning text, and a reminder that this will revert in 24 hours.  This reminder shows even if the script to stop the reversion has been executed.

Clicking Save brings up further warnings, a link to the security implications article referenced above and requests for the change to be Confirmed.

The Active Sites list now has an additional column to expose the Custom script settings, along with a useful new filter than shows all sites where custom scripts are set to Allowed.

The SharePoint admin could also choose to revert the changes, either through the UI, or via PowerShell, once the changes had been completed, rather than wait for the automatic reversion after 24 hours.  That probably isn't a bad idea.

This change has been introduced because of concerns over what custom script can do, and the scenarios this affects are not usually 'every day' occurrences within PWA.  However, I appreciate that this would require a SharePoint admin to get involved, which makes it more than a minor inconvenience.  We are still exploring what other options we might have here, but best to plan to need to involve the SharePoint Admins when doing these kinds of edits in future.  Although the issue uses the term 'custom script', many of the options that are blocked may not look like you are really doing any custom scripting - but it is more about what you 'could' be doing.  For example, editing a PDP to just add an Enterprise Custom Field doesn't add any custom script - but while editing you 'could' add a script editor web part that contains script.  It is more to ensure a conscious decision is being made about these actions.

We are also working on a Learn.Microsoft.com article which should be out shortly.  We should certainly have ensured the Message Center post also included Project Online explicitly, so sorry for the lack of communication and confusion around these changes.

Not applicable to PWA, but for reference.

One confusion is that the SharePoint Message Center post and subsequent article start off talking about the following section with the settings to allow users to run custom scripts on OneDrive and self-service created sites.  Project Web App does not come under this category of site, so this setting does not need to be enabled for the above scenarios to work.  The steps above are all that are needed. The settings page is also changing with the prevention on personal sites no longer being allowed to be changed.  It may look like this:

Or the latest screenshot of SharePoint Classic settings section on Custom Script looks like this one.  Either way, this doesn't apply to Project Online sites.