[E J]

Hi Jorah,

From a brute-force approach, I think you could rely on getting the NewForm/EditForm/DispForm properties of all lists in the list of sites that you’re reporting on.

Here’s an article with a CSOM and PS script that may work: https://www.sharepointdiary.com/2021/03/sharepoint-online-get-default-list-form-new-edit-display-urls-using-powershell.html

There seems to be a difference between the Modern slide-out default form URL and a Classic DFFS form URL, but I’m not sure how reliable that may be.

SPJS-DynamicFormsForSharePoint entries, in my experience, aren’t a guarantee that the form is still using DFFS.

I’m not aware if Sharegate has a report column that might shed light on New/Edit/Disp forms but that’s another possible option.

Would love to know what the best way to do this would be as well.

[E J]

Thanks for bringing this up!

Between v4.4.3.15 and v4.4.5.45, it looks like the trigger was changed from:

(v4.4.3.15 | CSS version: 4.37 |spjs-utility version: 1.312)
“If logged in user is in group with ID or name”

to

(v4.4.5.45 | CSS version: 4.51 |spjs-utility version: 1.356)
“SharePoint group membership: Logged in user is member of group”

On Modern SP Online (w/scripting) and Classic DFFS, the latter trigger fires but doesn’t seem to hide and then show the listed fields. “display: none;” never gets added to their css style.

Flipping it around to HIDE the fields if NOT IN the SP group worked for us. It was great to see this post and know we weren’t alone.

v4.4.3.15|CSS version: 4.37 / |spjs-utility version: 1.312

• This reply was modified 1 year, 9 months ago by E J. Reason: added version info

[E J]

No worries – I laughed when I read the documentation on MS’ site. “If you need these things the thing we forced you into doesn’t support, here’s a hack to go back to classic real quick!”. At the bottom of this page for anyone curious: https://support.microsoft.com/en-us/office/edit-a-rich-text-list-column-6ba62e7e-ee63-4716-9f95-f626770c3fff

Quite the headache for anyone trying to build a stable long-term 3rd-party solution for that. The load order for Modern UI has made knowing when to expect a DOM element to exist pretty annoying. Plus any [un|poorly]-documented black-box Classic fall-back code that may not extend well.

Excited with the progress so far! The experience so far has been really great.

[E J]

Hi Alexander,

Was this the issue where the “Return to classic experience” link for Modern Rich Text Editors was missing from the DFFS field UI?

I noticed HTML tables being something where the display worked but trying to get the editor to render them didn’t work without falling back to the classic experience RTE field. Quite the workaround from MS on that.

[E J]

Awesome – that’s exciting to hear. We’ll keep a look-out to see how that works!

[Author]

Posts