Fix classic form fallback on modern lists

This will fix the problem where the form is opened in the sidepanel without DFFS when you click to view, edit or add a new item from a modern list view.

Updated August 13, 2020

Great news! Microsoft has actually backed down and rolled back this breaking change yesterday!

It’s not all sunshine though because it will only be reversed for lists that have already been created and NOT for lists created from now and forward.

This means you must update to the latest DFFS installer to ensure it applies the necessary changes when installing in a new list.

Updated August 8, 2020

Microsoft admits to have broken the auto-detection of a modified form (with DFFS or other custom code) from a modern view, but won’t fix it. This means all Office 365 customers will get this error when the new version of SharePoint is rolling out.

ChangeLog

July 31, 2020 – v1.0.0.2

Fixed a bug where only the first 100 DFFS configurations in the SPJS-DynamicFormsForSharePoint list were checked. Also changed a jQspjs (jQuery noConflict namespace in DFFS) reference that made it only work when loaded in a DFFS form and not in a standalone page with plain jQuery loaded.


Microsoft is investigating the ticket i submitted yesterday regarding the breaking change or bug that was released for first release customers on Office 365link to my post from yesterday.

I have been able to create a script that fixes this problem on all DFFS enabled lists within a site (it must be run once for each site) by writing the NewFormUrl, DispForUrl and EditFormUrl to the content types for these lists. A big thanks to Earl Libby from SPMarketplace for helping me figure out this workaround!

I will release a new version of DFFS this weekend (August 8-9) where the DFFS installer is updated to include this fix.

This is what it does

  1. Gets all lists in current site to use in step 2
  2. Gets all stored configurations from the DFFS config list “SPJS-DynamicFormsForSharePoint” and gets all unique lists – finding the list GUID from the lists gathered in step one.
  3. Looping over all content types in all the DFFS enabled lists and checks if the NewFormUrl, DisplayFormUrl and EditFormUrl matches the current content type scope (the current list path) and if not update it.

How to use it

This script is designed to be dropped directly in the console of any page within a SharePoint site, but it needs jQuery to run so it may be best to open a list NewForm by typing in this in the browser address bar:

https://contoso.sharepoint.com/sites/YourSite/Lists/YourList/NewForm.aspx

The open the console and paste the script there.

I recommend using Google Chrome or the new Edge (chromium) as these have better console than Internet Explorer and the old Edge.

The script will log to the console so you know what is going on.

Please note that you need at least manage lists permissions to use this script. Also note that this only fixes lists that already have DFFS installed. This means that any new lists you install DFFS in might still fail unless you re-run this script. This will be fixed when I release a new version of the DFFS installer sometime later this week.

Get the script here

Link to script file (zipped).

Please let me know if you have any question in the comments below.

Best regards,
Alexander

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.