In einem meiner aktuellen Projekte galt es, Berechtigungen für eine bestimmte Benutzergruppe auf einen Work Item Type zu beschränken. Ein Blick in die Möglichkeiten der Berechtigungsverwaltung im TFS in der MSDN verrät bereits, dass man Berechtigungen für Work Items typischerweise über die Attribute Area- bzw. Iteration-Path steuert. Dies ist in den meisten Fällen auch eine praktikable Möglichkeit, da diese beiden Felder im Auslieferungszustand der Process Templates in jedem Work Item Type vorhanden sind. Im konkreten Fall ist dies jedoch kein tragfähiges Modell.
Das Szenario
Wenn man den TFS verwendet, um Projekte mit verschiedenen Geschäftspartnern zu koordinieren und durchzuführen, sollen nicht alle Benutzer die gleichen Berechtigungen haben. Ein Teil der Nutzer soll z.B. nur Bugs erstellen, jedoch sonst keine Work Items bearbeiten dürfen. Dieses vermeintlich triviale Szenario bringt das Berechtigungssystem des TFS und die vorgesehenen Use Cases jedoch schnell an ihre Grenzen.
Bestehende Konzepte
Eine kurze Online-Recherche zu dem Thema hat ergeben, dass sich natürlich bereits mehrfach mit dem Thema beschäftigt wurde. Dabei haben wir im Projekt konkret folgende Ansätze diskutiert:
- Work Item Only View (MSDN)
Der Work Item Only View, wie er in der MSDN beschrieben wird, ist ein Schritt in die richtige Richtung. Jedoch werden folgende Anforderungen nicht adressiert. Zum einen kann man nicht festlegen, dass nur ein bestimmter bzw. bestimmte Work Item Typen erstellt werden dürfen. Zum anderen gilt diese Einstellung lediglich im Web Access, beim Zugriff mittels anderer Clients, z.B. Visual Studio, kann man mittels Work Item Query auch auf andere Work Items zugreifen. - Restricting Work Item creation based on a role (Tiago Pascoal)
Tiago hat einen Weg beschrieben, der sich auf die Transitionen stützt. Dabei wird das Anlegen eines Work Items verhindert, wenn ein Benutzer Mitglied einer bestimmten Gruppe ist. Sobald ein Work Item jedoch existiert, kann man das Work Item auch wieder bearbeiten. Das hier geforderte Szenario wird zwar damit nicht gelöst, jedoch kann man den Weg über die Transitionen durchaus kombiniert mit dem hier beschrieben Modell verwenden (siehe unten bei “Nächste Schritte”). - Area / Iteration Path (Social-MSDN)
Auf social.msdn.microsoft.com wird ebenfalls über das Thema diskutiert. Jedoch läuft es dabei wieder auf den Weg hinaus, dass man Berechtigungen auf den Feldern Area- und Iteration-Path vergibt. In dem hier vorliegenden Fall sollen die Benutzer jedoch beim Anlegen des Work Items nicht in der Vergabe dieser Feldwerte beschränkt werden.
Lösungsweg
Einige Überlegungen führten zu der Erkenntnis, dass man für diese Konfiguration auf bestehende Felder zurückgreifen sollte. Außerdem sollte die Lösung noch mit vertretbarem Aufwand zu warten sein. Bei der Auswahl der Felder muss nun berücksichtigt werden, dass man ein Feld für diese Steuerung verwendet, welches dem System-Namespace entstammt, um losgelöst von Process Template spezifischen Anpassungen zu sein. Dies ist insbesondere bezüglich des Wartungsaufwands wichtig, damit man in jedem Work Item Type den gleichen Weg beschreitet.
Die Wahl ist hierbei auf das Feld Changed By (System.ChangedBy) gefallen. Dieses Feld hat den Vorteil, dass es bei jeder Änderung automatisch auf den Wert des aktuellen Benutzers gesetzt wird. Die im nachfolgenden Screenshot gelb hervorgehobene Erweiterung in der Felddefinition führt bereits zu dem gewünschten Ergebnis.
Dieses Feld wird beim Speichern des Work Items gesetzt. Durch den READONLY-Tag, mit der Bedingung für die Gruppe “RestrictedUsers” wird das Setzen des Wertes entsprechend verhindert. Das Feld verhält sich beim Anlegen eines Work Items ebenso wie bei einer Änderung. Dadurch kann man beide Fälle mit der Änderung abdecken.
Damit das sich das Process Template mit der oben dargestellten Änderung auf eine Team Project Collection hochladen lässt, muss man noch die entsprechende Gruppe “RestrictedUsers” anlegen. Dies geht ganz einfach durch Hinzufügen in folgender Datei:
Hat man das Process Template wie vorher beschrieben angepasst, so erhält man beim Versuch des nichterlaubten Speicherns folgende Fehlermeldung. Auch wenn diese Meldung verschiedene Fälle abdeckt, so erhält man immerhin auch einen Hinweis darauf, dass mangelnde Berechtigungen die Ursache sein könnten.
Diese Lösung kann sicherlich die fehlende Berechtigung auf Work Item Type Ebene nicht vollständig ersetzen. Auch ist sie nicht in jedem Falle anwendbar. In dem hier beschriebenen Szenario, hat sich dieser Weg jedoch als praktikabel herausgestellt und seine Vorteile gegenüber den anderen zur Wahl stehenden Alternativen ausgespielt.
Nächste Schritte
Mögliche Erweiterungen, die das beschriebene Vorgehen noch nicht beinhaltet sind beispielsweise die Erlaubnis ein Work Item anzulegen, es jedoch zu einem späteren Zeitpunkt nicht weiter bearbeiten zu dürfen. Wenn man das an einem bestimmten Reifegrad des Elements definieren kann, so würde sich für diese Erweiterung der Weg über die Transitionen anbieten.
Außerdem ist in den Standard-Templates das Feld “System.ChangedBy” nicht in allen Work Item Typen explizit definiert. Das gezeigte Beispiel entstammt der Erweiterung des Feature Work Items aus dem Process Temaplte VS Scrum 2013. Das Product Backlog Item beinhaltet die Felddefinition nicht. In dem Falle ist es sehr einfach, die komplette Felddefinition des System.ChangedBy Attributes aus dem Feature in das Product Backlog Item zu kopieren.
Wie vorher erwähnt, passt die Lösung sehr gut auf den spezifischen Fall. Weitere Alternativen zu dem Vorgehen oder andere Ergänzungen können gerne unten in den Kommentaren diskutiert werden.