Keine HTML-Erstellung in berechneten SharePoint-Feldern mehr möglich

Das kam überraschend: am 13. Juni 2017 kündigte Microsoft aus recht heiterem Himmel an, dass die Erstellung von HTML-Markup über Berechnete Felder (Calculated Columns) nicht nur nicht mehr offiziell supported ist, sondern auch aktiv unterbunden wird. Für SharePoint Online trat diese Änderung quasi mit dem dazugehörigen Supportticket ein, für SharePoint Server 2013 und 2016 kommt sie mit dem nächsten CU Update. Wer auch immer diese Herangehensweise zur Darstellung von beispielsweise bedingten Bildern oder KPIs in Listenansichten benutzt hat, sollte das dringend überprüfen und handeln.

Die Benutzung von Berechneten Feldern für die Darstellung von Inline-HTML in einer Zelle einer SharePoint-Liste ist nach meiner Beobachtung weit verbreitet, da hiermit sehr schnell und ohne Scripting-Kenntnisse Änderungen herbeigeführt werden können. Wer es nicht kennt: Fügt man HTML Tags über Logiken in den berechneten Feldern zusammen, wird dieser HTML Code tatsächlich zur Laufzeit eingesetzt und kann damit die Darstellung in der jeweiligen Zeile beeinflussen.

Nun ist das dummerweise ein Pattern, welches von Microsoft niemals wirklich unterstützt wurde. Ich kann mich daran erinnern, dass findige Geister diese Herangehensweise bereits unter SharePoint 2007 gerne für schnelle Modifikationen benutzten. Dementsprechend verbreitet ist die Methode trotz fehlendem Segen des Herstellers und diesem waren derartige Modifikationen wohl auch nicht ganz geheuer, was ich sogar aus softwaretechnischen Gründen recht gut nachvollziehen kann.

Im Microsoft’schen Sprech hört sich das dann so an:

Some users have added HTML markup or script elements to calculated fields. This is an undocumented use of the feature, and we will begin blocking execution of custom markup in calculated fields in SharePoint Online from June 13, 2017 onwards. We are also providing this as a configurable option for on-premises in SharePoint Server 2016 and SharePoint Server 2013 via the June 2017 and subsequent Public Updates.

Kleine Entwarnung zu on-prem Installationen

Administratoren können sich in SharePoint Online eine Verschiebung bis September über den Support erfechten, müssen hier aber selber tätig werden. Bei on-prem Installationen gibt es nach dem Update ebenfalls eine kleine Gnadenfrist:

• Bestehende Webanwendungen verbleiben erst einmal in dem Modus, dass HTML Escaping nicht stattfindet.
• Neue Webanwendungen werden mit dem Default-Switch versehen, dass HTML Escpaing stattfindet.
• Bestehende Webapplikationen können per PowerShell so konfiguriert werden, dass sie ebenfalls HTML Escaping durchführen.

Bedeutet: on-prem ändert sich nach der Installation des Patches erst einmal nichts. Die Einstellung ist eine Eigenschaft am SPWebApplication Objekt und kann – Rechte vorausgesetzt – recht einfach per PowerShell manipuliert werden.

Migrationen auf neue SharePoint Versionen

Interessant wird die Sache allerdings für Migrationen, die aktuell geplant werden: Wenn Inhalt aus einer alten SharePoint Umgebung auf eine neue 2013 oder 2016 Version erfolgen und dort das aktuelle CU eingespielt worden ist vor der Erstellung der Webanwendungen, muss auf jeden Fall geprüft werden, ob die migrierten Inhalte diese Modifikationen über die berechneten Felder nutzen. Andernfalls kann es sein, dass die Felder in den Listenansichten nichts mehr anzeigen.

Daher ist es ratsam, vor der Datenmigration einmal zu prüfen, ob es in den zu migrierenden Webs solche Modifikationen gibt.

Alternativen zu berechneten Feldern

Bleibt die berechtigte Frage, was denn nun als Alternative eingesetzt werden soll. Aufgrund des recht strikten Changes werden auf kurz oder lang auch die Hintertürchen (Verschieben der Umstellung bei SharePoint online oder die Konfiguration per Switch on-prem) keine sinnvolle Option darstellen.

Die Verwendung dieses Pattern hatte schon immer ein bisschen den Nimbus der Flickschusterei bzw. des „Reinfummelns“ von gewünschten Darstellungen durch einen Trick. Dabei gibt es dazu einige Alternativen.

JS Link

Die meisten einfachen Modifikationen können durch clientseitiges Skripting erschlagen werden. Microsoft bietet seit SharePoint 2013 die Möglichkeit, Listenansichten durch die Beigabe eines Links zu einer JavaScript-Datei recht einfach zu modifizieren. Dazu wird in den jeweiligen Webparteigenschaften eine hochgeladene .js-Datei angegeben:

Als ein schnelles Beispiel für das Verständnis der Modifikation einer Spalte kann neben vielen anderen das hier gut genutzt werden.

Zu beachten ist dabei allerdings, dass JS Link nur in der klassischen Ansicht von SharePoint funktioniert. Wenn man beispielsweise bereits die Modern Sites einsetzt und dort entsprechende Bibliotheksansichten hat, steht einem dieses Feature hier nicht mehr zur Verfügung.

Third-Party Tools

Die galanteste und wahrscheinlich teuerste Möglichkeit, das Problem aus der Welt zu schaffen, sind Third-Party Tools, die einen erst gar nicht in die Verlegenheit kommen lassen, berechnete Felder für solche Anforderungen zu benutzen. State of the Art ist hier sicherlich Skybow, da es den Benutzern über eine Klick-Oberfläche ermöglicht, das Rendering einzelner Spalten umfassend zu verändern. Aber auch KwizCon und viele weitere, kleinere Tools können hier Abhilfe schaffen.

SPfx Erweiterungen

Die wohl „genehmste“ Alternative aus Sicht von Microsoft besteht in der Nutzung des SharePoint Frameworks zur Erstellung einer Ansicht, die gewünscht ist. Dieses steht aktuell nur unter SharePoint Online zur Verfügung, wird aber im Herbst mit dem nächsten Feature Pack auch auf on-premise Systeme seinen Einzug finden.

Hier ist allerdings der IT-Pro, der vielleicht „mal eben“ ein kleines Customizing gemacht hat, definitiv raus. Das SharePoint Framework ermöglicht Entwicklern einen sehr einfachen Zugangspunkt zur clientseitigen Programmierung von Erweiterungen, hat aber in dieser Form nichts mehr mit dem Baukasten zu tun, den viele „PowerUser“ für solche Anwendungsfälle nutzen können.

Langfristig: PowerApps

Auch das ist der Weg, den Microsoft immer stärker gehen wird, wie sie es in der Roadmap auf dem Virtual Summit 2017 im Mai angekündigt haben. PowerApps und Flow als Ersatz für InfoPath und auch weite Teile des SharePoint Designers erlauben weitgehende Modifikationen der Oberfläche in SharePoint Online. Aber auch das ist aktuell noch Zukunftsmusik und wird seinen Weg auf on-prem Installationen wohl niemals finden.

Kommunikation von Microsoft

Was man bei dem ganzen Dilemma allerdings noch einmal festhalten sollte, ist die Kommunikation auf Seiten von Microsoft. Gerade für SharePoint Online ist es eigentlich ein Unding, den Erstellern von Lösungen auf Basis der Plattform exakt null Zeit zu lassen, Ihre Installationen und Lösungen zu überprüfen. Ein wenig ohne wirkliche Not wird keine Ankündigung für die Zukunft gemacht sondern direkt Vollzug gemeldet.

Auch die Kommunikation in Richtung der Patches wirkt mindestens unglücklich. Da gibt es halt ein kleines Supportticket, und ohne die obligatorische Hilfe von diversen MVPs, Gruppen und Communitykanälen wäre diese Info dort wohl auch versackt.

 

Bildquelle: NYC Fire Escape https://www.kickingdesigns.com/2013/01/nyc-fire-escape-1-1-2013/