Smarter Business hat den MS Gold Partner Status!

Was dir das bringt, fragst du dich? Du profitierst aus unserer engen Zusammenarbeit mit Microsoft, denn der Goldstatus ermöglicht es uns, auch dir das absolute Maximum an Benefits und Know-how zu bieten.

Die stetige Weiterbildung unseres Teams, die erfolgreiche Umsetzung von Projekten mit unseren Kunden und die kontinuierliche Weiterentwicklung unserer Lösungen lässt nicht nur unseren Erfahrungsschatz weiterwachsen, sondern ermöglicht uns es auch, diesen Rang auch weiterhin behaupten zu können.

Bei aller Bescheidenheit zum Trotz, müssen wir diese Zeilen loswerden – es ist immerhin der höchstmöglich zu erreichende Partnerstatus und man ist mit der Vergabe naturgemäß eher geizig. Obwohl es eine Vielzahl an Microsoft Partner Unternehmen gibt, erreichen doch weltweit nur ein Prozent davon den Gold Partner Status. Microsoft vergibt diesen Status exklusiv an jene Unternehmen, die für ihre Kunden nicht nur hervorragende Lösungen erarbeiten, sondern auch außerordentlichen Service bieten. Wir sind daher zu Recht stolz, uns einen Microsoft Gold Partner nennen zu dürfen!


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.