Trac: Erstellung, Plugins, Permissions und mehr


DatumÄnderung
14.10.2011Erste Version
20.10.2011Informationen zum Login hinzugefügt, kleine Korrekturen
29.06.2012Aktualisierte Abbildungen (neues Weboberflächen-Design)
29.06.2012Abschnitt "Ticketsystem" hinzugefügt

1 Einleitung

Trac ist ein sogenanntes Projektmanagement-Werkzeug, welches euch, wie der Name schon sagt, euch bei euren Projekten unterstützt. Es bietet dafür verschiedene Module:

  • Ein Wiki
  • Zeitleiste
  • Roadmap
  • Quellcodebrowser
  • Ticketsystem

Es ist dabei durch Plugins frei erweiterbar. Auf der Seite Trac-Hacks findet ihr eine Liste der meisten verfügbaren Plugins. Würdet Ihr gern eine bestimmte Funktionalität in unserer Trac-Installation sehen, eröffnet einfach ein Ticket oder schreibt dem Support eine Mail, in dem/der ihr die gewünschte Funktionalität, oder besser ein spezielles Plugin, beschreibt.

2 Trac-Instanz erstellen

Instanzen von Projektmanagement-Werkzeugen sind auf unserem Server immer direkt an ein Repository geknüpft. Das heißt, dass ihr genau so viele Trac-Instanzen wie Repositories besitzen könnt. Selbst solche, die ihr ohne ein verknüpftes Repository erstellt, werden im Hintergrund mit einem Dummy-Repository verknüpft, wodurch die Anzahl auch dort auf zur Zeit zehn Stück begrenzt ist.

2.1 Erstellung ohne ein Repository

Dies ist die einfachste Art, eine Instanz von Trac zu erzeugen. Hierführ navigiert ihr zum Trac-Bereich (zum Beispiel über die Shortcuts auf der linken Seite), wählt den Punkt Trac-Instanz ohne Repository erstellen aus, wählt einen passenden Namen und drückt auf Werkzeug erstellen.

Abb.1: Trac-Bereich, Erstellung einer Instanz ohne verknüpftes Repository.
Abb.1: Trac-Bereich, Erstellung einer Instanz ohne verknüpftes Repository.

2.2 Erstellung mit verknüpftem Repository

Um diese Aufgabe zu erledigen, müsst ihr zuerst ein Repository beliebiger Art anlegen, welches ihr mit Trac managen möchtet - wie ihr das macht, könnt ihr (bald) in entsprechenden Tutorials nachlesen.

Es gibt zwei Orte, an denen eine mit einem Repository verknüpfte Trac-Instanz angelegt werden kann: Auf der Repository erfolgreich erstellt-Seite (Abbildung 2) und in den Details eines Repositories (Abbildung 3) existieren Buttons, die lediglich darauf warten, angeklickt zu werden.

Abb.2: Erstellung einer Trac-Instanz direkt nach der Erstellung eines Repositories - hier Subversion.
Abb.2: Erstellung einer Trac-Instanz direkt nach der Erstellung eines Repositories - hier Subversion.

Abb.3: Erstellung einer Trac-Instanz aus den Details eines Repositories - hier Subversion - heraus.
Abb.3: Erstellung einer Trac-Instanz aus den Details eines Repositories - hier Subversion - heraus.

3 Die Details einer Trac-Instanz

Nachdem du eine Instanz erstellt hast, kannst du jederzeit in den Trac-Bereich unserer Seite zurückkehren und ihren Namen anklicken, um ihre Details zu betrachten.

Trac ist hier relativ einfach gestrickt, sodass es hier nur drei wichtige Punkte gibt:

  1. Berechtigte Benutzer: Dieser Link führt dich zum Permissionsystem deiner Trac-Instanz. Trac verwaltet seine Permissions selbst, sodass dies nichts mit der Weboberfläche, auf der du dich grade befindest, zu tun hat. Näheres dazu findest du weiter unten.
  2. Gleiches gilt eigentlich ebenfalls für den Pluginbereich, jedoch verzichten wir auf unserem Server aus Sicherheitsgründen darauf, sodass ihr durch einen Klick auf zu den Plugineinstellungen! zu unserer Pluginverwaltung kommt.
  3. Im unteren Bereich findet ihr Informationen, wie Ihr auf die Trac-Instanz zugreifen könnt. Denke daran, dass alle Dienste, die dieser Server anbietet, auf dem Fachbereich4-Account basieren, nicht auf dem HTW-Account!

Abb.4: Die Details einer Trac-Instanz.
Abb.4: Die Details einer Trac-Instanz.

4 Auswahl von Plugins

Dieser Bereich ersetzt die eigentlich in Trac enthaltene Pluginverwaltung. Er besteht aus der Information, welche Trac-Instanz ihr da eigentlich bearbeitet, und einer Tabelle aller vorhandener, ein- und ausschaltbarer Plugins. Scheut euch nicht, alle Plugins ein mal zu probieren, denn sie können auch wieder deaktiviert werden. Falls euch die Kurzbeschreibung nicht ausreicht, ist in der linken Spalte im Namen ein Hotlink zur offiziellen Homepage des Plugins hinterlegt.

Änderungen der Plugineinstellungen werden generell nach einem Klick auf Änderungen Übernehmen sofort übernommen und mit einer Bestätigungsnachricht im oberen Bereich der Seite quittiert.

Abb.5: Die verfügbaren Plugins einer Trac-Instanz.
Abb.5: Die verfügbaren Plugins einer Trac-Instanz.

5 Permissions

Das Permissionsystem basiert, sehr ähnlich der Rollen im SQL-Standard, auf sogenannten Subjects, welche nicht zwischen einzelnen Benutzern und Gruppen unterscheiden. Dazu ein einfaches Beispiel: Ist einem Subjekt namens Hans die WIKI_ADMIN-Permission zugeordet, kann sowohl ein Benutzer, der sich erfolgreich mit dem Namen Hans anmeldet, als auch andere Benutzer, welche dem Subjekt (hier im Sinne von Gruppe) zugeordnet sind, das Wiki administrieren.

In Trac existieren zwei besondere Subjects: anonymous wird nicht angemeldeten Benutzern automatisch zugewiesen. Angemeldete Benutzer bekommen hingegen neben einem Subjekt gleichnamig zu ihrem Login-Namen (z.B. s0123456) auch das Subjekt authenticated zugewiesen.

In einer Standard-Installation sind diesen beiden Standardsubjekten gewisse Rechte vorgegeben: Anonyme Nutzer haben können alles sehen, autentifzierte zusätzlich fast alles ändern. Diese Standard-Permissions stellen in unserem Umfeld ein Sicherheitsrisiko dar, da der Login gegen das gesamte Benutzerverzeichnis des Fachbereich 4 durchgeführt wird - jeder Benutzer mit einem Fachbereich-4-Account kann sich also generell anmelden!

Da jedoch die meisten Projekte nicht-öffentlich sind und schon gar nicht jeder Student fast alles ändern können soll, haben wir diese Standardrechte entfernt, sodass sich zwar jeder Student anmelden kann, aber keine Rechte hat, was einem Nicht-Login gleichzusetzen ist. Das ist der Grund, warum im Vergleich zu Trac-Standardinstallationen in der Permissiontabelle direkt nach der Erstellung einer Trac-Instanz keine Einträge für diese beiden Subjekte auftauchen.

Stattdessen existieren die beiden Subjekte (Gruppen) developer und priviledged, welche auf Erfahrungswerten beruhen. Erstere sind normale Entwickler, die alles sehen und zusätzlich das Ticketsystem benutzen und das Wiki administrieren können. In einem größeren Projekt, an dem der ganze Kurs mitwirkt, ist das die ideale Gruppe für die meisten Studenten. Letztere Gruppe hat zusätzlich alle verbleibenden Rechte außer TRAC_ADMIN, kann also zum Beispiel keine Permissions verteilen, um den eigentlichen Admin nicht ausstechen zu können. Diese Gruppe ist für den oder die studentischen Projektleiter geeignet, falls der Dozent als Besitzer der Trac-Instanz seine Krone (TRAC_ADMIN) nicht abgeben möchte.

Beispiel

Direkt nach der Erstellung einer Trac-Instanz sieht eure Permission-Tabelle so aus, wie in Abbildung 6 dargestellt. Man sieht die von uns vorgegebenen Subjekte developer und priviledged, sowie das TRAC_ADMIN-Recht für den Besitzer. Löscht das niemals, ansonsten dürft ihr eine Mail an den Support schreiben!

Abb.6: Permissions direkt nach der Trac-Erstellung
Abb.6: Permissions direkt nach der Trac-Erstellung

Nehmen wir nun an, es gäbe einen freundlichen Studenten s0123456, der am Projekt mitarbeiten möchte. Dazu Benutzen wir das Feld Add Subject to Group, geben seine Matrikelnummer als Subjekt an und developer als Gruppe (Abb.7).

Abb.7: Zuweisung eines Subjektes an ein anderes Subjekt als Gruppe
Abb.7: Zuweisung eines Subjektes an ein anderes Subjekt als Gruppe

Dieser Student hat von dem Dozent nun den Auftrag bekommen, sich um die Pflege von Milestones zu kümmern. Wir geben ihm also noch alle Rechte, die mit Meilensteinen zu tun haben, indem wir im Feld Grant Permission seine Matrikelnummer als Subjekt und die entsprechende Permission angeben (Abb.8).

Abb.8: Zuweisung einer Permission an ein Subjekt
Abb.8: Zuweisung einer Permission an ein Subjekt

Da wir die Außenwelt über unser prima Projekt informieren möchten, geben wir anonymous auch noch das Recht, sich das Wiki anzusehen (Abb. 9).

Abb.9: Zuweisung der WIKI_VIEW-Permission an anonyme Nutzer
Abb.9: Zuweisung der WIKI_VIEW-Permission an anonyme Nutzer

Nach diesen Aktionen sollte die Permissiontabelle so aussehen wie in Abbildung 10.

Abb.10: Neue Permissiontabelle nach den Änderungen
Abb.10: Neue Permissiontabelle nach den Änderungen

Und noch ein Hinweis: Auch, wenn Trac leider den Begriff Subject nicht durchgängig verwendet und je nach Kontext auch mal User oder Group über den Bildschirm flimmert, ist es immernoch ein vollwertiges Rollensystem wie in SQL! Rechte können rekursiv über Subjekte hinweg vererbt werden, sodass eine alternative Möglichkeit, unsere Standardrechte zu implementieren, die in Abbildung 11 gezeigte sind: Das Subjekt priviledged erbt alle Rechte von developer und erhält zusätzliche Rechte.

Abb.11: Alternative Darstellung unserer Standard-Rechte
Abb.11: Alternative Darstellung unserer Standard-Rechte

6 Benutzung

Zu guter Letzt soll an dieser Stelle eine kleine Einführung in die Benutzung von Trac gegeben werden. Sie ist nicht dazu gedacht, die umfangreichen tiefgreifenden Hilfen und anderen Tutorials im Internet zu ersetzen, sondern soll gerade Anfängern einen schnellen und frustfreien Start in die Benutzung von Trac ermöglichen.

6.1 Wiki

Abb.12: Das integrierte Wiki
Abb.12: Das integrierte Wiki

Trac bringt ein voll funktionsfähiges Wiki mit, was natürlich grade für besonders große Projekte sehr wichtig ist. Nach der Erstellung der Instanz beinhaltet das Wiki eine Kopie des Trac-Wikis zur aktuell verwendeten Version und bietet somit seine eigene umfangreiche Online-Hilfe, auf die vom gesamten Trac aus zugegriffen werden kann, gleich selbst mit.

Bitte habt Verständnis dafür, dass es bei den Anpassungen, die wir hier für unseren Server anwenden müssen, vorkommen kann, dass einige Einträge sich leicht von der tatsächlichen Situation unterscheiden. Über einen kleinen Hinweis per Mail über solch eine gefundene Stelle würden wir uns freuen.

6.2 Timeline

Abb.13: Die Timeline - eine Chronik des Projekts
Abb.13: Die Timeline - eine Chronik des Projekts

Die Zeitleiste eures Projektes stellt Änderungen am Wiki, an Tickets, an Meilensteinen und, falls vorhanden, am Repository übersichtlich dar.

6.3 Roadmap

Abb.14: Planung von Meilensteinen
Abb.14: Planung von Meilensteinen

Meilensteine sind festgelegte Zwischenziele in einem Projekt. Sind einem Meilenstein Tickets zugeordnet, wird ein Fortschrittsbalken mit dem Verhältnis zwischen offenen und abgeschlossenen Tickets angezeigt, sowie Shortcuts zu jeweils offenen, geschlossenen oder allen Tickets dieses Meilensteins.

6.4 Source Code Browser

Abb.15: Browsen durch das Repository
Abb.15: Browsen durch das Repository

Falls einer Trac-Instanz ein Repository zugeordnet ist, könnt ihr es hier ähnlich wie direkt im Browser durchsuchen. Allerdings bietet der Code Browser Tracs ungleich mehr Funktionen: Es wird neben der Größe auch die Revisionsnummer, das Alter und die Commit-Message des aktuellsten Standes der entsprechenden Datei oder des entsprechenden Ordners angezeigt. Außerdem können einzelne Dateien oder das gesamte Repository zu einer bestimmten Revision angezeigt (Kontrollen oben), Changesets (auf Rev. klicken) betrachtet und der Unterschied einer Datei zwischen zwei beliebigen Versionen (auf Datei klicken) untersucht werden.

6.5 Ticketsystem

Dies ist das wohl wichtigste Modul Tracs. Tickets sind mit klassischen ToDo-Zetteln zu vergleichen. In ihnen ist der Name der Aufgabe, eine Beschreibung, der Übermittler, der Bearbeiter und vieles mehr festgehalten - spätestens mit dem Benutzen von Plugins sind der Phantasie dort keine Grenzen gesetzt. Im Abschnitt zum Admin-Panel wird auf die meisten dieser Felder eingegangen, da die angebotenen Optionen dort bearbeitet werden können.

Es ist nirgendwo festgeschrieben, wie genau so ein Ticketsystem zu benutzen ist. Von naja, eigentlich sind es nur Notizzettel bis hin zum Ticketsystem für große Firmen mit tausenden Tickets ist alles drin. Aus diesem Grunde wird hier auch nicht näher auf den Ticket Workflow eingegangen, da ihr mit ein wenig Herumprobieren euren ganz eigenen herausfinden werdet.

Wichtig hier sind noch die sogenannten Reports, welche hinter dem Menüpunkt View Tickets stecken. Tickets werden nicht generell einfach in einer Liste angezeigt, sondern in einer Tabelle, die eine Datenbankabfrage hinter sich hat. So listet Active Tickets zum Beispiel alle Tickets, die nicht den Status closed besitzen. Normalerweise sollten die vorhandenen Abfragen vollkommen ausreichen, jedoch können auch neue Reports angelegt werden. Ein interessanter Zusatz zum WHERE-Teil einer Abfrage wäre zum Beispiel:

WHERE owner == 's0123456'

, wobei natürlich deine eigene Matrikelnummer eingesetzt werden sollte, um nur Tickets dieses Benutzers anzuzeigen.

6.6 Suche

Abb.16: Projektweite Suche
Abb.16: Projektweite Suche

Zu diesem Bereich gibt es wohl am wenigsten zu sagen: Er erlaubt das Durchsuchen aller Tickets, Changesets, Meilensteine und des gesamten Wikis.

6.7 Admin-Panel

Abb.17: Die Schaltzentrale der Trac-Instanz
Abb.17: Die Schaltzentrale der Trac-Instanz

Hier könnt ihr alle euch erlaubten Einstellungen (außer Plugins) vornehmen, braucht also keinen Zugriff auf eine Kommandozeile auf dem Server, um trac-admin-Kommandos abzusetzen, wie es einem das Internet manchmal weis machen möchte.

Der Bereich teilt sich in zwei Bereiche auf: General und Ticket System. Alle Punkte des letzteren Bereiches lassen euch mögliche Werte für gleichnamige Eigenschaften bei Tickets erstellen. Falls ihr den ein oder anderen nicht benötigt, könnt ihr bei all diesen Punkten die entsprechende Funktion deaktivieren, indem ihr alle Werte der Eigenschaft entfernt.

6.7.1 Basic Settings

Hier könnt Ihr eurem Projekt einen anderen Namen geben (die URL ändert sich dabei nicht), ihm eine ausführliche Beschreibung verpassen und eine URL angeben. Da das Trac-Icon links oben immer auf die Studi-Seite verlinkt und die Zusammenfassung aller Projekte durch Trac im Moment deaktiviert ist, sind diese Einstellungen im Moment eher nutzlos.

6.7.2 Permissions

Siehe Permissions weiter oben.

6.7.3 Components

Abb.18: Komponenten im Admin
Abb.18: Komponenten im Admin

Komponenten eures Projektes, denen ihr Tickets zuordnen könnt. Das kann zum Beispiel so etwas wie Backend, Frontend und Android-App sein, aber auch etwas abstraktes wie Dokumentation - eurer Phantasie ist keine Grenzen gesetzt.

6.7.4 Milestones

Abb.19: Meilensteine im Admin
Abb.19: Meilensteine im Admin

Hier werden die Daten von Meilensteinen bearbeitet. Ihr könnt ihnen Namen, Beschreibung, vorgesehenes und tatsächliches Fertigstellungsdatum geben. Als Beispiel sei hier natürlich die ganz wichtige Abgabe eines Projekts genannt!

6.7.5 Priorities

Abb.20: Prioritäten im Admin
Abb.20: Prioritäten im Admin

Hoch ist die niedrigste Priorität, richtig?

6.7.6 Resolutions

Abb.21: Lösungen im Admin
Abb.21: Lösungen im Admin

Wie wurde dieses Ticket geschlossen? Gefixt? Bug gar nicht vorhanden? Duplikat? Es bietet sich an, gerade für simple Aufgaben-Tickets ein done hinzuzufügen.

6.7.7 Severities

Abb.22: Dringlichkeiten im Admin
Abb.22: Dringlichkeiten im Admin

Eine Option, die oft nicht benötigt wird, da bereits die Priorität eine ausreichende Einteilung der Tickets bietet. Kleiner Tip: Ihr könnt hier - wie in allen anderen Ticket-Eigenschaften - eintragen, was ihr wollt. Ob nun leicht und schwer, S, M und L oder mandatory und optional...

6.7.8 Ticket Types

Abb.23: Ticket-Typen im Admin
Abb.23: Ticket-Typen im Admin

Hier ist defect (Bug), enhancement (neues Feature) und task (Aufgabe) voreingestellt und sollte selbsterklärend sein.

6.7.9 Versions

Abb.24: Versionen im Admin
Abb.24: Versionen im Admin

Zu guter Letzt könnt ihr Tickets also auch Versionen zuordnen. Ist ein Feature zu schwer für Version 0.1? Kein Problem, einfach auf Version 0.2 verschieben!