Dienstag, 7. Oktober 2014

Powershell Scripts - Alternative Sprachen (Sprachpakete) in allen Websites aktivieren

Wer SharePoint mit mehreren Sprachen betreiben möchte, weiß dass es dazu grundsätzlich zwei Möglichkeiten gibt: Die sprachenabhängige Anpassung der Oberfläche über Sprachpakete sowie die Trennung der Inhalte in verschiedene Sprachen (sogenannte Variations). Das letztere ist ein eigenständiges Thema. Wir möchten in diesem Beitrag  kurz auf ein spezielles Thema / Problem beim Einsatz von Sprachpaketen eingehen.

Sobald man zusätzliche Sprachpakete auf dem SharePoint installiert hat (übrigens, hier immer darauf achten dass man unter Umständen auch die Service Packs für die Sprachpakete installieren muss), stehen die zusätzlichen Sprachen grundsätzlich zur Verfügung.

Ein Sprachpaket ermöglicht die Umschaltung auf eine der anderen Sprachen. Dieses Umschalten stellt alle SharePoint Standard Oberflächen Funktionen auf die jeweilige Sprache um, außerdem ist es damit möglich in der jeweils aktiven Sprache die Namen von Listen, Spalten sowie Navigationselementen anzupassen.

Der Nachteil ist allerdings dass die zusätzlichen Sprachen pro Website aktiviert werden müssen, um auch genutzt werden zu können. Da hier keine Vererbung möglich ist, ist der einfachste Weg (vor allem bei bereits bestehenden Websites) die zusätzliche Sprache über ein kleines Powershell Script zu aktivieren.

Ein einfaches Powershell Script dass für alle Websites einer anzugebenden URL einfach alle installieren Sprachpakete aktiviert wäre das folgende:

# Enables SELECTED installed languages for each subsite in a site collection
 $spSite = Get-SPSite -Identity
http://DemoURL
 foreach ($spWeb in $spSite.AllWebs)
 {
   $spWeb.IsMultilingual = $true
   $WebRegionSettings = New-Object Microsoft.SharePoint.SPRegionalSettings($spWeb)
   foreach ($language in $WebRegionSettings.InstalledLanguages)
   {
        write-host -BackgroundColor Green -ForegroundColor Black "Update -" $spWeb "site with LCID:" $language.DisplayName
        $culture = New-Object System.Globalization.CultureInfo($language.LCID)
        $spWeb.AddSupportedUICulture($Culture)
   }
   $spWeb.Update()
 }


 

Dieses Script bzw. die Logik davon kann man natürlich z.B. auch mittels einem Event Receiver und dem sogenannten Feature Stappling als SharePoint Solution bereitstellen, die automatisch bei jeder neu angelegten Website die Sprachen aktiviert.

Montag, 15. September 2014

Wir beziehen unser neues Firmengebäude

Nach knapp 1-jähriger Bauzeit ist es endlich geschafft. Unser neues Firmengebäude steht und wird von uns am 27.09.2014 bezogen.

Damit schaffen wir Platz für weiteres Wachstum und können auch unseren Gästen einen angenehmen Rahmen für Besprechungen und Präsentationen bieten.

Wir begrüßen Sie gerne ab dem 29.09.2014 an unserer neuen Adresse:

Siller Portal Integrators GmbH
Pfaffenstraße 66
74078 Heilbronn
Tel.: 07131/7240-500
Fax: 07131/7240-599
contact@s-pi.de
www.s-pi.de

Die bisherigen Kontaktdaten, wie email-Adressen, Telefon- und Faxnummern bleiben bestehen.

Dienstag, 9. September 2014

Tipps/Tools - Problematik Berechtigungen in InfoPath Views in Kombination mit Pflichtfeldern

Wenn man wie z.B. bei einem Investitionsantrag/Bedarfsmeldung Formular mit InfoPath die Anforderung hat, dass bestimmte Personen/Gruppen nur Teile des Formulars sehen können, dann lässt sich das glücklicherweise bequem und einfach über die Views/Ansichten in InfoPath regeln. Diese lassen sich ja auch Benutzer/Benutzergruppenspezifisch manuell oder automatisch wechseln bzw. aufrufen.

Oftmals ist es so, dass bestimmte Felder Pflichtfelder sind, allerdings nur für bestimmte Gruppen. Wenn z.B. derjenige der eine Bedarfsmeldung genehmigt in seiner Ansicht noch zusätzliche Felder ausfüllen muss, die der Antragssteller gar nicht sehen darf. Die einfachste Lösung wäre hierbei ja das Feld einfach als Pflichtfeld zu definieren.
Leider kann das in diesem Fall allerdings nicht genutzt werden. Denn ein Feld das als Pflichtfeld definiert ist muss immer ausgefüllt werden, auch wenn es in einer Ansicht (wie z.B. beim Antragssteller) gar nicht sichtbar ist.
Für dieses Problem gibt es nur einen sinnvollen Lösungsansatz:
Eigene Validierungs-/Pflichtfeld Regel
Diese leider unter Umständen etwas aufwendige Variante basiert auf der Erstellung von eigenen Regeln für die Erkennung von Pflichtfeldern und Darstellung von entsprechenden Meldungen. Diese kann dann am einfachsten direkt auf den Speichern/Absenden Button angewendet werden. Leider ist dies natürlich unter Umständen recht aufwendig, je nachdem um wie viele Pflichtfelder und damit Validierungen es geht.

Für das gewünschte Pflichtfeld muss eine Custom Validation  mit einer Regel erstellt werden: Bedingung 1: Feld ist leer
Optional könnten für diese Regel  mit einer weiteren Bedingung z.B. Ausnahmen für bestimmte Benutzer geschaffen werden. 
Außerdem darf man das Attribut „Darf nicht leer sein" nicht setzen. Diese Custom Validation Regel muss für jedes gewünschte Pflichtfeld gesetzt werden.
 

Nintex Workflows - Display Namen aus einem Personen- oder Gruppenfeld in einer E-Mail anzeigen

Das Versenden von E-Mail Benachrichtigungen gehört zu einer der am häufigsten genutzten Aktionen in Nintex Workflows. Wer schon einmal versucht hat ein Person- oder Gruppenfeld in der Benachrichtigung zu referenzieren, den wird aufgefallen sein, dass in der E-Mail nicht der Anzeigename angezeigt wird. Stattdessen werden Personen in der Form „i:0#.w|domain\username" dargestellt. Das sieht natürlich unschön aus und ist nicht wirklich praktikabel.

Um auch in der E-Mail den Anzeigenamen anzuzeigen, gibt es mehrere Möglichkeiten. Eine Möglichkeit wäre, den Anzeigename aus dem Active Directory bzw. dem SharePoint Benutzerprofil abzufragen. In Nintex stehen hierfür folgende Aktionen zur Verfügung: Query LDAP, Query User Profile (Enterprise Version) oder Call a Webservice. Es geht aber noch einfacher:
Alles was dazu benötigt wird, ist eine „Set variable" Aktion und eine neue Variable in der die Anzeigenamen gespeichert werden. Die Variable kann vom Typ „Single line of text" sein. Satt der Variable direkt das Feld zuzuweisen (Equals Value), wird ein List Lookup verwendet.

 
 
 
Das List Lookup hat den entscheidenden Vorteil, dass neben dem ausgewählten Feld ein Button angezeigt wird, der es ermöglicht den Rückgabetyp auszuwählen. Hier wählen Sie „Display Names, Semicolon Delimited".
 
 
Jetzt kann die Workflowvariable, die die Anzeigenamen aus den Personenfeld hält, einfach in der E-Mail Benachrichtigung referenziert werden.  
 

Bildbibliotheken: Lightbox ähnliche Ansicht integrieren

Leider ist es in SharePoint nach wie vor nicht möglich eine typische Lightbox View für Bildbibliotheken darzustellen. Hierbei öffnet man ein Bild und kann dieses dann in einer Art PopUp Fenster, das den Hintergrund ausblendet, betrachten und mit Navigationselementen wie z.B. Pfeilen zum nächsten oder vorherigen Bild navigieren.

Um solch ein Verhalten in SharePoint 2010 zu erhalten, gibt es verschiedene Möglichkeiten. Entweder man setzt dazu auf den Seiten der jeweiligen Bildbibliotheken kleine jQuery Code Schnipsel ein, oder setzt auf fertige Webparts.
Einige Beispiele für die Einbindung solcher Code Schnipsel sind hier zu finden: (diese können auch in Masterpages hinterlegt werden):
http://blog.mikehacker.net/2009/06/10/sharepoint-photo-gallery-using-jquery/


Beispiele für durchaus gute und funktionsfähige günstige oder kostenlose Webparts sind hier zu finden:
http://www.codeproject.com/Articles/781797/Picture-Thumbnails-Web-Part-SharePoint

Im Falle von SharePoint 2013 gibt es noch eine andere Möglichkeit. Hier kann bereits im Standard eine Art Vorschau mit Klick auf die drei Punkte "..." geöffnet werden. Mittels einer kleinen jQuery Implementierung kann dann in exakt diesem Vorschaufenster zum nächsten oder vorherigen Bild navigiert werden. Diese Lösung wurde von uns im Rahmen eines Kundenprojektes entwickelt, kann aber bei allen Standard Bildbibliotheken eingesetzt werden.
Sollten Sie Fragen zu den Lösungen haben können wir Sie gerne unterstützen.

Nintex Workflow 2013 – Fehler beim Setzen von Berechtigungen

Nintex Workflows erlauben das Anpassen der Elementberechtigungen mit der „Set item permissions" Aktion. Mit dem neuesten Release von Nintex Workflow 2013 (v3.0.8) wurde ein Fehler im Zusammenhang mit dieser Aktion behoben. Bei früheren Versionen gab es einen Bug, der das korrekte Setzen der Elementberechtigungen verhinderte.

Die Ursache des Problems ist allerdings nicht auf den ersten Blick erkennbar, denn der Workflow stoppt nicht an der Aktion, die die Elementberechtigungen setzt, sondern erst an folgenden Aktionen bei denen Benutzer Berechtigungen auf das Element benötigen (z.B. bei einer Workflowaufgabe zur Genehmigung des Elements). In der Workflow History wird auch nur ein Fehler im Workflow aufgeführt. Das Problem liegt in diesem Fall an den Elementberechtigungen. Sämtliche Berechtigungen wurden vom Element entfernt ohne die neuen Berechtigungen zu erteilen.

Dieses Problem tritt nicht nur im Zusammenhang mit Service Pack 1 für SharePoint 2013 auf. Wir empfehlen daher das Update von Nintex Workflow auf die aktuelle Version 3.0.8. Weitere Informationen zum aktuellen Release finden Sie hier:


 

Freitag, 1. August 2014

InfoPath Formulare mit anonymen Zugriff für Internetseiten

Prinzipiell ist der anonyme Zugriff von InfoPath Formularen nur in Sonderfällen in Betracht zu ziehen, da er ein hohes Sicherheitsrisiko birgt. Daher ist diese Funktion auch von Microsoft bewusst in den Grundeinstellungen deaktiviert. Wer in SharePoint seinen Webauftritt und die InfoPath Formulare für anonyme Nutzer bereitstellen möchte, muss einiges beachten.
Folgende Schritte sind nötig:

1. In der Zentraladministration für die Internet Zone ist "Anonymous Access" zu aktivieren. Diesen Dialog findet man unter CA-> Application Management->Manage Web Applications –> <Auswahl der Webanwendung> –> Authentication Providers –> <Auswahl der Zone für anonymen Zugriff (z.B. Internet) –> "Enable anonymous access" Haken setzen


2. Stellen Sie sicher, dass für diese Zone keine Anonymous Policy "Deny" gesetzt ist


3. InfoPath Formular in einer Bibliothek veröffentlichen;
"Datei –> Veröffentlichen" und die Felder der Form-Bibliothek bestimmen.  Nach dem Upload erscheint folgende Meldung:


Wer danach das Formular mit einem angemeldeten Benutzer aufruft, kann es sofort nutzen. Sobald man nicht mehr angemeldet ist, bekommt man eine schöne Correlation-ID und im ULS Log diese Meldung:

 "The XSN is null and it´s not a cross server issue. Most likely a permission issue"


Man muss dann mit einem Trick die Berechtigung der Formular- Bibliothek anpassen:
Klick auf "Library Permissions" –> Anonymus Access
 


 Im Modul-Fenster bestimmt man mit "rechtsklick –> Eigenschaften" die URL

 


Copy the url and paste it on new tab in your browser and change the DOCLIB word with LIST like thisDiese URL kopiert man in die Adressleiste des Browsers und ersetzt DOCLIB durch List.

 

Danach ist man in der Lage die Berechtigungen für die Bibliothek zu setzten:

 

HINWEIS: Wenn Sie erneut in die Bibliothek und auf die Berechtigungen gehen, sind die Funktionen „bearbeiten", „hinzufügen" und „löschen" wieder deaktiviert und grau hinterlegt, so dass eine Bearbeitung nicht möglich ist. Wenn Sie in der URL DOCLIB durch List ersetzen, sind die zuvor von Ihnen getätigten Änderungen wieder ersichtlich.