Daniel Esser

Momentan beschäftige ich mich intensivst mit dem Team Foundation Server. Eine Sache die mir recht früh aufgefallen ist, ist dass die Benutzer im Assigned-To-Feld von Work Items auch alle Service Accounts beinhalten. Meines erachtens ein Schönheitsfehler. Darüberhinaus ist aber auch nicht ganz klar wie z.B. Benutzer Work Items zugeordnet werden können die vielleicht nicht direkt mit dem Team Foundation Server arbeiten, also vielleicht keine Rechte im System besitzen.

In aktuellen Fall ist es so, dass Anforderungen ihren entsprechenden Stakeholdern zugeordnet werden müssen. Diese Stakeholder legen Ihre Anforderungen aber im ersten Schritt nicht selbst im TFS an, sodass diese auch von der Berechtigungsstruktur her erstmal nicht in einem Team Project verankert sind.

Zum Berechtungshintergrund:

  • Auf der Team-Project-Ebene gibt es prinzipiell vier vordefinierte Gruppen: Buildes, Contributers, Project Administrators und Readers. In keine der genannten Gruppen passt der oben genannte Stakeholder der Anforderungen (sofern er nicht aktiv die Anforderungen bearbeitet oder sogar anlegt).
  • Auf der Team-Project-Collection-Ebene gibt es: Administrators, Build Admins, Build Serice Accounts, Proxy Service Accounts, Service Accounts, Test Service Accounts und Valid Users.

Keine der oben genannten Gruppen erscheint richtig für die genannten Stakeholder bis auf die recht offen benannte Gruppe Valid Users. Shauen wir uns diese Gruppe einmal genauer an.

Wie wir oben sehen können sind die Standard-Team-Project-Gruppen hier eingetragen, sowie die restlichen Standard-Team-Project-Collection-Gruppen. An dieser Stelle sei angemerkt, dass dies der Grund ist warum in „Assigned To“-Feldern der Work Items auch die Service Accounts auftauchen. Weitere Anmerkung; löschen ist vermutlich nicht ratsam, da damit auch Berechtigungen verloren gehen.

Wie dem auch sei, im Screenshoot oben ist deutlich zu sehen, dass die Gruppe nicht editierbar ist. Es können also keinen weiteren Mitglieder in diese Gruppe aufgenommen werden. Allerdings würde hier unsere Stakeholder von oben gut hinein passen. Wie lässt sich dies nun bewerkstelligen ohne in große sicherheitskonzeptionelle Problematiken zu kommen?

Zunächst starten wir die Team Foundation Server Administration Console. Von dort aus über den Application Layer, die Team Project Collections, das Tab Genral und dann auf Group Membership.

Im nun folgenden Dialog auf New… und einen Gruppen-Namen vergeben. Ich habe dort den Namen Project Collection Participants vergeben aber es steht natürlich jedem frei einen sinnvolleren Namen zu vergeben. Nun könnte man sich die Frage stellen wie uns diese Gruppe dabei hilft weitere Menschen, in diesem Fall weitere Stakeholder, in die Valid Users Gruppe zu bekommen? Hier kommt uns aber eine Kuriosität des TFS zu hilfe.

Wenn wir uns die Eigenschaften der gerade neu angelegten Gruppe anschauen und dort auf das MemberOf-Tab gehen wird man festestellen, dass die neue Gruppe bereits Mitglied der Valid Users Gruppe ist. Das ist nicht wirklich intuitiv, vor allem da beim hinzufügen der Gruppe diese Beziehung nicht ersichtlich war. In unserem Fall ist diese Tatsache aber von nützen, da wir nun Stakehoder in die neue Participants-Gruppe stecken können, welche direkt die eingeschränkten Rechte der ValidUsers-Gruppe erben und zusätzlich nun auch in den entsprechenden AssignedTo-Feldern der Work Items aufauchen.

Der lezte und zugleich einfachste Schritt ist nun die entsprechenden Stakeholder in die neue Participants-Gruppe aufzunehmen, welche dann sogleich in den dazugehörigen AssignedTo-Feldern aufauchen.