(openPR) Beim Entwickeln für größere Produkte – wie im Falle von TickX für SharePoint – stellt man sich bei neuen Anforderungen als erstes die Frage: gibt es bereits eine Funktionalität, die den Ansprüchen genügt? Wenn ja, hat sie unter Umständen das Potential, später erweitert zu werden?
Gerade als Entwickler will man entwickeln. Und neigt schnell dazu, Features auf eigene Art umsetzen zu wollen, selbst wenn man das Rad dabei neu erfindet. Aber übersehe ich als Entwickler nicht vielleicht im Basisprodukt vorhandene Features, die genügen, um die neuen Anforderungen hinreichend abzubilden?
Ein Beispiel, bei dem wir weitestgehend auf zusätzliche Entwicklung verzichtet haben, ist die Genehmigung der Artikel. SharePoint bietet ein auf Haupt- und Nebenversion basierendes Verfahren, dass Artikel zunächst nur für den Autor und Benutzer mit speziellen Rechten zugreifbar macht. Hier haben wir lediglich eine Option hinzugefügt, dass Mitglieder der Genehmigergruppe per E-Mail über das Vorhandensein des ausstehenden Artikels informiert werden können.
Das Teilen eines Artikels dagegen ist eine Anforderung, die nicht nach unseren Wünschen und den Erwartungen unserer Kunden verfügbar war. Zwar ist das Freigeben von Elementen eines der prominenteren Features von SharePoint, hat jedoch im Kontext eines Helpdesk Systems einige Einschränkungen, die u.a. durch das Berechtigungssystem von SharePoint bedingt sind:
Zunächst wird für das Vergeben von Berechtigungen ein authentifizierter Benutzer voraussetzt. (Anonyme Anmeldung für die Webanwendung stand nicht zur Debatte.) Kontakte der Kunden sind jedoch meist – interner Support als Ausnahme – nicht im Active Directory gepflegt und können sich ohne Authentifizierungsanbieter wie formularbasierte Authentifizierung nicht am SharePoint anmelden.
Deshalb haben wir uns für das Feature entschieden, Artikel als E-Mail verschicken zu können. Mit E-Mails haben wir die Möglichkeit, beliebige Kontakte auch außerhalb unserer SharePoint-Farm zu erreichen. Als Techniker kann ich einen Artikel der Knowledge Base öffnen und gelange über eine Schaltfläche im Ribbon in ein Formular, in dem ich Empfänger angeben und eine individuelle Einleitung für die E-Mail vergeben kann. Bei der Auswahl der Empfänger werde ich dabei durch eine Auto-Vervollständigung für in TickX bekannte Kontakte unterstützt. Die E-Mail setzt sich dann aus der Einleitung und dem kompletten Artikel zusammen.
In der aktuellen Version haben wir das Versenden via E-Mail um die Option ergänzt, den Link* zu dem Artikel in den Textkörper einzufügen. Dies erwuchs aus der Anforderung eines TickX-Kunden, dessen Mitarbeiter Artikel häufig untereinander teilen. In diesem Szenario hatten die Empfänger bereits Zugriff auf den Artikel und können deshalb über die Artikel-URL auf die Knowledge Base zugreifen. Nun hätten wir den Kunden natürlich auf das SharePoint-Feature zum Freigeben verweisen können – doch ist es aus Sicht des Kunden verständlich, nicht zwei Funktionen für fast identische Ziele nutzen zu wollen. Außerdem hat das Freigeben auch in diesem Fall Implikationen, die es in seinem praktischen Nutzen einschränken: zum einen ist der Funktionsumfang von der SharePoint-Version (Foundation/Server) abhängig, zum anderen sind die Berechtigungen in der Knowledge Base auf Listenebene verwaltet. Ein Freigeben von Einzelelementen bräche die Vererbung der Berechtigungen auf und sorgt dafür, dass man schnell den Überblick über die Zugriffsrechte verliert.
*technische Details im Follow-Up-Artikel zu URLs und SharePoint-Zonen
http://www.tickx.de
