Custom markup in SharePoint calculated columns

[Chris McNulty]

Earlier this week, we published an update on Message Center to advise selected tenants  about a change in the operation of SharePoint.  To sum up, we removed an undocumented, unsupported behavior that allowed custom markup script inside calculated fields for classic view.  

One of our primary responsibilities to our customers is to protect the integrity and stability of the service.   Executing custom markup in calculated fields was creating ongoing risks to platform performance, availability, integrity and stability.    

We understand that closing this loophole has had an adverse impact on some customers, and requires additional work to move your customizations to supported patterns and features.   Please know that we are meeting in the product team daily to consider the best ways to support your organizations, and to review your thoughts and comments.  We are actively advising our support and customer teams to assure we have the best set of guidance and solutions available to them, and to you.    We’ll continue to aggregate our best guidance in our KB article at https://support.microsoft.com/en-us/help/4032106/handling-html-markup-in-sharepoint-calculated-field...

Presently, if an administrator would like to continue the use of custom markup in classic calculated fields, they can request the capability to be reactivated until September 10 (90 days after the announcement) after they accept the risks associated with the behavior by contacting Support.

For users of classic-mode user experiences, customers should consider using administrator-deployed JSLink and Custom Action capabilities to further customize the presentation of list views. 

For modern sites, and as we disclosed at SharePoint Virtual Summit in May 2017, we have plans to introduce declarative (code-free) custom field views, conditional formatting and related capabilities to modern views later this year.  In addition, SharePoint Framework has introduced a new Field Customizer object that can be used within code-based solutions to create custom field handlers. 

Whether you are using classic based views or modern experiences, these options provide more robust customization support for tailored field and list views.  

Please let’s continue the dialog here.  @Lincoln DeMaris

[#2]

We were heavily using this functionality in loads of our sites. It is unbelieveble this functionlity was removed before the anouncement. It was removed at 13th of june in the morning while the anouncement was placed in the afternoon. Thereafter it took 2days before I got a first reply to my case about this (a critical case). After the first phone contact it will take 5 business days before the change is done! How could someone think this was a good idea? 

[#3 · Accepted solution]

It is great to get the explanation for these things that impact so many.

[#4]

I have no problem with removing the behvaior. The problem is how it was deployed and not giving customers and the community not even a day to act on it. That is not a professional service as this impacts a lot of business-critical solutions. The 90 day reactivation should have been announced as "We will block this in 90 days".

[#5]

Here a blog post I've put together on how to use JS Link to render the calculated fields as HTML. 

SharePoint Calculated Fields with JS Link

Hope it helps. 

[#6]

The background of your site is very cool! How did you do that?

[#7]

I couldn't agree more. No one is fooled by the "security risk" argument because this example of Msft's leaky programming was in heavy use for 10+ years. But regardless - if they all of a sudden woke up and decided as part of their "stop customization" campaign that this was an issue, they should have notified all users that it was going to be removed and provided a reasonable enough amount of time for THEM to come up with a seamless client side transition. Expecting users to solve their problems is a classic example of how Msft transfers the cost of their poor development practices onto users.

No other company would even consider making a change lilke this that impacts production sites without due notice. Disgraceful!  

[#8]

JSLink works well on standard list view, but if you add to a Map View it then displays the Map View as a standard list...?

[#9]

This is absolutely outrageous.  I support my site for a fortune 10 insurance company and this functionality just disappears???  And you are "WORKING" on something, why didn't you wait until you had that SOMETHING ready????

[#10]

We haven't removed any functionality. We've closed off an undocumented workaround, true, but we've given an option to accept that risk and temporarily reenable the "hack".

We know that this still has an impact on our customers, and we're working to improve what you can do with supported customizations.

That said, we've also previewed conditional field formatting at SVS and hope to release a fully supported capability relatively soon. More to share later this year!

[#11]

What we have done for a customer that is still "no modern" is just to create some JavaScript that replaces the HTML calculated fields for real HTML so they don't lose functionality. For modern SPO sites we have to wait until the SPFx extensions leave the preview status to do just the same

[#12]

Here is the official fix, at least for on-premise:

# NOTE:  =$False  NOT  ="$False"
# In SharePoint 2016 Management Shell, run...

$Web = Get-SPWebApplication http://weburl
$Val=$Web.CustomMarkupInCalculatedFieldDisabled=$False
$web.update()

# To confirm it is now false...

$Web.CustomMarkupInCalculatedFieldDisabled

[#13]

We have all found workarounds for what we felt were limitations in the product. Important to see both sides here: Microsoft is probably shocked at how customers have found workarounds, and customers are shocked that Microsoft would disable the ability to leverage aforementioned workaround. That being said, while communicating this better would have been appreciated, I'm also surprised that anyone would use a non-supported workaround in a production environment for a Fortune 100 customer. Unless of course said workaround was kept a secret from their client...Fortune 100 or otherwise.

[#14]

This debacle was extended to September and then Feb 2018 because even Msft realized it was poorly handled. I now have some instances of it still working and some not. Where is the official documentation on when this FUNCTIONALITY will finally be removed? And yes, Chris, in an environment where the most useful functionality is developed by users, this "undocumented feature" IS indeed "functionality" you are removing.

[#15]

Google isn't producing any solutions that doesn't require scripting. Is there a built in solution yet?