[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 2 months, 2 weeks 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