Bildergalerie in SharePoint Bildbibliothek

Bei einem Kunden kam die Frage auf, ob es andere Möglichkeiten für die Darstellung und Navigation in SharePoint Bildbibliotheken gibt. Da der SharePoint Standard nicht wirklich benutzerfreundlich ist und es auch kaum Einstellmöglichkeiten gibt, habe ich ein wenig im WWW gestöbert. Dabei bin ich auf eine Möglichkeit gestoßen, die nur wenig Anpassungen benötigt um in SharePoint 2013 zu funktionieren (wurde bis jetzt nur auf SharePoint 2013 getestet).

 

Anleitung zum Erstellen einer Bildergalerie in SharePoint

  1. Zuerst ist ein Ordner zu erstellen, in dem die benötigten Dateien abgelegt werden. In meinem Fall habe ich den Ordner „ImageGallery“ unter dem Pfad „Siteurl/StyleLibrary/“ angelegt.
  2. Jetzt muss die Galleria Bibliothek oder mein Zip-File heruntergeladen werden. Davon werden folgende Dateien benötigt:
  • query-1.11.0.min.js
  • galleria-1.3.5.min.js
  • classic.min.js
  • classic.css
  • classic-map.png
  • classic-loader.gif
  1. Diese Dateien in den zuvor erstellten Ordner speichern und zusätzlich eine Datei „DisplayGallery.txt“ erstellen.
  2. Als nächstes muss die Bildbibliothek erstellt werden, für welche die Galerie verwendet werden soll.
  3. Bei dieser Bibliothek muss nun eine neue Ansicht erstellt werden. Diese muss auf der „Alle Bilder“ Ansicht basieren und zeigt nur den [Namen] der Dateien.

  1. Jetzt muss eine neue Seite erstellt werden, auf der der Webpart der Bildbibliothek eingefügt wird. Dabei wird als Standardansicht die zuvor ausgewählte Ansicht gewählt.

  1. Zum Schluss muss noch ein Inhalts-Editor Webpart eingefügt werden. Dieser verlinkt nun die „DisplayGallery.txt“ Datei.

  1. Falls du den Ordner an einem anderen Pfad abgelegt hast, muss dieser Pfad an vier Stellen in der „DisplayGallery.txt“ Datei angepasst werden.


Term Store Manipulation im Elevated-Code-Block

Änderungen auf dem TermStore mit dem System-User: Das kann doch nicht so schwer sein, oder?

So oder zumindest so ähnlich, war unsere erste Annahme bei der Planung eines eigenen Bearbeitungstools für den Terminologie-Store für SharePoint 2013. Die Anforderung war simpel: Von einem bestimmten Knoten weggehend sollte der TermStore für eine eingeschränkte Benutzergruppe bearbeitbar sein. Grund dafür ist die Menge an neu hinzugefügten Terms, und die Problematik, dass SharePoint es nicht mehr zulässt - selbst wenn die TermSets geöffnet sind, und die User Terme hinzufügen dürfen - diese später nochmals zu bearbeiten oder zu löschen.

Also, was tun? Alle betreffenden User im TermStore berechtigen?

Dies kam in unserem Fall nicht in Frage, da nicht alle Terms im TermStore oder in einem TermSet für alle Benutzer veränderbar sein sollten. Schnell wurde klar, dass eine selbst entwickelte Oberfläche (auf einer Layoutspage), welche die Bearbeitung eingeschränkter Terme möglich macht, die Lösung ist. In dieser Oberfläche sollen die User neue Terme anlegen, bestehende löschen und auch umbenennen können. Ebenfalls sollte es hier möglich sein, zusätzliche Eigenschaften hinzuzufügen.

Aber wie können User ohne Berechtigung Änderungen am Term Store vornehmen?

Und hier kommen wir zur Krux der ganzen Sache. Unsere Lösung war, den Code einfach mit Elevated-Privileges auszuführen und den System-User im TermStore zu berechtigen. Klingt zuerst einmal simpel, und hatte auch funktioniert, solange wir mit Usern getestet haben, welche auch Berechtigung auf dem TermStore hatten. Die Probleme kamen erst mit Test-Usern, welche keine Berechtigung auf den TermStore hatten.

Aber wieso sollte das so sein? Es wird ja in beiden Fällen der System-User verwendet, also war uns nicht klar, warum es mit einem User der Berechtigungen auf den TermStore hat, funktioniert und mit den anderen Usern eben nicht. Nach vielen Recherchen und langem Debugging wurde dann klar, dass das Problem die TaxonomySession istZuerst hatten wir den Code in etwa so, wie in dem nachfolgenden Code-Snippet:

Anzunehmen ist, dass - da die SPSite und das SPWeb innerhalb der Elevated-Privileges initialisiert werden - auch die TaxonomySession,  welche als Konstruktor-Argument die SPSite mitbekommt, ebenfalls unter dem Kontext des System-Users erstellt wird.

Wie beim Debugging aufgefallen ist, ist dies aber nicht der Fall. Anscheinend übernimmt die TaxonomySession die Daten des derzeitigen Users aus dem derzeitigen HttpContext. Was mich auch zur Lösung des Problems bringt:

Um die TaxonomySession davon abzuhalten, den User aus dem HttpContext zu beziehen, setzen wir vor dem Elevated-Code-Block den HttpContext.Current auf null. Dies zwingt den TermStore die Userdaten aus der WindowsIdentity zu nehmen, und wir können nun im Kontext des System-Accounts nach Belieben Terms hinzufügen, entfernen oder bearbeiten!

Wichtig ist nur, dass NACH dem Elevated-Code-Block der HttpContext wieder auf den vorherigen Wert gesetzt werden muss, da sonst einige Dinge wie z.B. der SPContext nicht mehr funktionieren.

Ich hoffe ich konnte euch ein bisschen Zeit sparen,

liebe Grüße euer Josef


SharePoint Designer: Der Zeitstempel

Es war einmal... ein SharePoint Designer Workflow, oder so ähnlich :)

Aufgund einer vor kurzen aufgetretenen Kundenanforderung, musste ich mich mit einer eigentlich simplen Thematik dann doch einige Zeit herumschlagen. Diese war nichts anderes, als einfach in den logischen Workflow Blöcken einen Zeitstempel zu integrieren um eine spätere Auswertung zu ermöglichen.

Da ich längere Zeit nicht mehr mit dem SPD gearbeitet hatte, war ich dann doch verblüfft, dass es hier keine Standardlösung von Microsoft gibt. Im weiteren Verlauf meiner Recherche fand ich heraus, dass diese Problematik seit 2009 (!) bekannt ist und es dafür verschiedenste - mehr oder weniger - schlechte Workarounds gibt, welche aber allesamt weit entfernt von einer sinnvollen oder performanten Lösung sind.

Nun gut, ich habe mich dann für meinen eigenen Ansatz entschieden. Und zwar, dem Kunden eine simple Lösung bereitzustellen, welche noch dazu wiederverwendbar ist - denn das ist was wir tun - Lösungen generieren. ;)

Die Rede ist hier von einer kleinen aber effektiven Sandbox Workflowaktion, welche genau die gegebene Anforderung erfüllt. Nämlich einen Zeitstempel zu generieren.

Was benötigt man dazu?
1) Leere Visual Studio SharePoint Sandbox Solution erstellen
2) Neues Element vom Typ Modul hinzufügen
3) Das autogenerierte "Elements.xml" bearbeiten
4) Eine Klasse mit dem Code bereitstellen
5) Deployen, Einbinden &... Profit!

Wie sieht das nun aus und was kommt in die Files?

Inhalt der Elements.xml:

 

Inhalt der Code Datei:

 

Und das war's eigentlich auch schon. Das ganze Builden und in die /_catalogs/solutions Bibliothek hochladen und aktivieren. Danach steht die Aktion auch schon ohne Zeitverlust oder Application Pool Neustart im SharePoint Designer zur Verwendung bereit und kann wie alle anderen Aktionen eingefügt werden.

 

Dauer der ganzen Aktion: 5-10 Minuten und man hat die Möglichkeit, innerhalb des Workflows Zeitstempel zu protokollieren.

Für alle die es noch einfacher wollen, stellt euch Smarter Solutions hier die Sandkasten WSP mit Site Feature als Download bereit.