Des Öfteren kommt die Anforderung nur die eigenen erstellten Elemente im SharePoint für sich sichtbar bzw. bearbeitbar zu machen. Gerade bei Umfragelisten ist dies zum Teil unumgänglich.
Dies kann bei SharePoint Listen recht problemlos über die Listeneinstellungen > Erweiterte Einstellungen ermöglicht werden, wie auf dem folgenden Screenshot zu sehen ist.
Wenn der Use Case sich dabei auf den einfachen Prozess einer Umfrageteilnahme oder dem Einstellen eigener Elemente ohne Sichtbarkeit für andere Mitglieder der Site erstreckt, dann ist die Nutzung dieser Einstellungen vollkommen ausreichend.
Auch für die Anforderung, dass bestimmte User (z.B. Superuser oder Administratoren) alle Elemente sehen dürfen, um z.B. die Umfrage auszuwerten, sind auch diese Einstellungen hier angemessen.
Wann macht es Sinn die Berechtigungen anzupassen?
Anders sieht es hingegen aus, wenn die Prozess komplexer werden. Zum Beispiel:
- eine Stellvertreter-Regelung muss berücksichtigt werden,
- die Hierarchie umfasst neben Mitgliedern und Administratoren noch Gruppenleiter, welche die Elemente ihrer Mitarbeiter sehen dürfen, aber nicht die anderer Gruppen,
- der Original-Ersteller muss nach Export/Import bzw. Kopiervorgängen beibehalten werden,
- oder ein Element bzw. dessen Inhalt will ausnahmsweise doch mit Anderen geteilt werden.
Darüber hinaus stehen diese Einstellungen nicht für Dokumentenbibliotheken zur Verfügung.
Die konkreten Details dieser Funktion liegen in den programmatischen Listeneigenschaften SPList.ReadSecurity und SPList.WriteSecurity, welche für die gesamte Liste eingestellt werden. Wie daran zu sehen ist, haben diese Eigenschaften nichts mit den Berechtigungen zu tun, die dann auch direkt an den Elementen hängen.
Interessanterweise existieren diese beiden Eigenschaften auch für Dokumentenbibliotheken und lassen sich über das Server Side Object Model setzen. Dann funktioniert die Logik zwar auch im SharePoint, aber über WebDav z.B. über die Windows Explorer Verbindung ist der Zugriff auf die eigentlich geschützten Dateien anderer User trotzdem möglich.
Somit bleiben für die komplexeren Lösungen bzw. Dokumentenbibliotheken zuverlässig dann nur programmatische oder Workflow gestützte Lösungen übrig. Dabei sollten unbedingt die Überlegungen und Hinweise berücksichtigt werden, die ich in Teil 3 beschrieben habe.
