Der TFS bietet ein Berechtigungskonzept, welches auch die Work Items einschließt. Für Work Items gelten zunächst einmal die Grenzen des Teamprojektes, in dem sie enthalten sind. Innerhalb eines Teamprojektes, lassen sich die Berechtigungen zum Anzeigen und Editieren von Work Items auf Area-Level festlegen. Areas bieten dabei folgende Rechtetabelle an:
Die Abbildung zeigt, die Rechte auf dem Area-Knoten „Specification“ eines Beispielprojektes. Diese sind für unseren Beispielnutzer entzogen. Versucht dieser Nutzer, auf diesem Knoten, Berechtigungen einzusehen oder zu editieren, bekommt er eine Fehlermeldung.
Man könnte meinen, dass das Recht “View this node” einschließt, dass der Knoten z.B. in einem Work Item Formular sichtbar bzw. versteckt bleibt. Doch ist dem nicht so. Areas und Iterations sind generell sichtbar, wenn man im TFS nicht die Metadaten nach Berechtigungen filtert (siehe Blog von Martin Woodward).
Die Reports hingegen kümmern sich nicht um Work Item Security. Alle Daten, die ein Report abfragt sind dem Nutzer, der den Report ansehen darf zugänglich (read-only). Das liegt daran, dass die Berichte als User ReportService o.ä. auf das Data-Warehouse zugreifen und das Rechtekonzept dort nicht so feingranular umgesetzt wird. Man muss sich also genau überlegen, wer auf welche Reports zugreifen darf.
Hier ein Beispiel für einen Work-Item-Bericht, der auch Work Items aus der “sicheren” Area (siehe oben) anzeigt.
Und das obwohl der Benutzer keine Berechtigung hat, dieses Work Item direkt mit dem TFS zu öffnen.
Das vorgestellte Konzept sollte in die Überlegungen zum Aufbau einer Teamprojektstruktur einfließen. Je nachdem, welche Sicherheit benötigt wird, muss man in mehrere Teamprojekte aufteilen und von einem einzelnen Teamprojekt absehen bzw. sich dafür entscheiden, mehr Informationen sichtbar zu machen.