Version 1.4.3 · Redmine 5.1 und 6 · GPLv2
Dieses Handbuch beschreibt Installation, Konfiguration und täglichen Einsatz des atori Kanban-Board-Plugins.
Das Plugin ergänzt eine projektbezogene Kanban-Ansicht, die direkt auf die in Redmine definierten Ticket-Statuswerte abgebildet wird. Es gibt keinen parallelen Workflow, kein separates Status-Modell und keine Schattendaten: Spalten sind Statuswerte, Karten sind Tickets, und jede Änderung auf dem Board ist ein reguläres Redmine-Ereignis mit dem entsprechenden Journaleintrag.
Zentrale Begriffe:
IssueStatus. Spalten lassen sich im Board-Settings-Dialog ausblenden oder umsortieren; ausgeblendete Spalten existieren in Redmine weiter, erscheinen aber nicht auf dem Board.IssueQuery). Über Queries erreicht man beliebig komplexe Filterlogik, ohne im Plugin eine eigene Abfragesprache nachzubauen.Version) gilt als Sprint. Das Plugin erfindet kein eigenes Sprint-Modell, sondern nutzt die bereits in Redmine vorhandenen Versionen mit ihrem optionalen Start- und Fälligkeitsdatum.cd /pfad/zu/redmine
unzip at_kanbanboard-1.4.3.zip -d plugins/
bundle exec rake redmine:plugins:migrate NAME=at_kanbanboard RAILS_ENV=production
# Redmine neu starten (passenger/puma/systemd-Unit)Nach dem Neustart als Administrator einloggen und Administration → Plugins öffnen. Das Plugin Kanban Board sollte mit Version 1.4.3 erscheinen, ohne Fehler-Banner.
cd /pfad/zu/redmine
bundle exec rake redmine:plugins:migrate NAME=at_kanbanboard VERSION=0 RAILS_ENV=production
rm -rf plugins/at_kanbanboard
# Redmine neu startenDer Rake-Task rollt alle Plugin-Migrationen zurück und entfernt die drei vom Plugin verwalteten Tabellen (kanban_boards, kanban_board_columns, kanban_issue_positions). Bestehende Redmine-Daten (Tickets, Status, Abfragen) werden nicht angerührt.
Kanban ist als Projekt-Modul implementiert und standardmäßig deaktiviert.
Das Plugin stellt drei unabhängige Rechte unter Administration → Rollen und Rechte → Kanban-Board bereit:
| Recht | Wirkung | Typische Rolle |
|---|---|---|
| Kanban-Board ansehen | Board sehen, nur lesend | Berichterstatter |
| Tickets auf dem Kanban-Board bearbeiten | Drag & Drop, Reihenfolge innerhalb einer Spalte | Entwickler |
| Kanban-Board verwalten | Board-Einstellungen ändern (Kartenquelle, Swimlanes, WIP, Spaltensichtbarkeit) | Manager |
Die Trennung von Lese- und Bearbeitungsrecht erlaubt es, reinen Stakeholdern Zugang zu gewähren, ohne versehentliche Statuswechsel zu riskieren.
Beim ersten Aufruf des Kanban-Tabs durch einen Benutzer mit Kanban-Board ansehen-Recht wird der Board-Datensatz automatisch angelegt. Eine Spalte pro Ticketstatus wird in der Reihenfolge erzeugt, die Redmine vorgibt; geschlossene Status sind enthalten, können aber nachträglich über die Board-Einstellungen ausgeblendet werden.
Innerhalb eines Projekts mit aktiviertem Kanban-Modul erscheint im Projektmenü der Eintrag Kanban (nach Tickets). Der Klick öffnet das Board mit den aktuellen Tickets, angeordnet nach Status.
Benutzer mit dem Recht Tickets auf dem Kanban-Board bearbeiten können Karten zwischen Spalten ziehen. Das Ablegen löst ein Status-Update am zugrunde liegenden Ticket aus, das durch Redmines normale Workflow-Prüfung läuft – Workflow-Beschränkungen pro Rolle und Tracker werden also respektiert. Ein Journaleintrag wird genauso geschrieben, als hätte man den Status über das reguläre Ticket-Formular geändert.
Das Umsortieren von Karten innerhalb einer Spalte wird in der plugin-eigenen Positionstabelle (kanban_issue_positions) gespeichert und berührt keine Ticketdaten. So lässt sich Priorität auf dem Board ausdrücken, ohne das Prioritätsfeld zu überschreiben.
Standardmäßig zeigt das Board alle Tickets des Projekts. Um die Menge einzugrenzen:
Das Board zeigt nun nur noch die Tickets, die die gespeicherte Abfrage liefert. So lässt sich das Board auf einen Sprint, ein Release, einen Zuständigkeitsbereich oder jede andere Dimension eingrenzen, die sich bereits als Query formulieren lässt.
In den Board-Einstellungen ein Swimlane-Feld wählen. Unterstützt werden:
Leere Auswahl deaktiviert Swimlanes und stellt das Standard-Layout mit einer einzigen Zeile wieder her. Swimlanes sind rein eine Anzeigeeinstellung; ihr Ein- oder Ausschalten ändert keine Ticketdaten.
Pro Spalte lässt sich eine positive Ganzzahl als Grenze setzen. Übersteigt die sichtbare Kartenanzahl das Limit, zeigt der Spaltenkopf eine Warnung. Das Plugin blockiert bewusst keine weiteren Züge – harte Blockaden führen erfahrungsgemäß dazu, dass Arbeit am Tool vorbei organisiert wird, und unterminieren damit den Sinn des Limits.
Um das Limit einer Spalte aufzuheben, Eingabefeld leeren.
In den Board-Einstellungen:
Über den Sprint-Filter oben am Board lässt sich die angezeigte Ticketmenge auf eine einzelne Redmine-Zielversion einschränken. Das Auswahlfeld listet alle für das Projekt sichtbaren offenen Versionen (shared_versions.open), sortiert nach Fälligkeitsdatum. „Alle (kein Filter)" entfernt die Einschränkung.
Sobald ein Sprint gewählt ist, erscheint unter dem Filter ein Sprint-Streifen mit:
Der Streifen ist farblich kodiert: grün im Plan, gelb wenn weniger als zwei Tage Restlaufzeit, rot bei überfälligem Sprint-Ende. Die Werte werden bei jedem Aufruf neu aus den Tickets der Version berechnet, also ohne separat gepflegten Sprint-Status.
Tickets ohne Sprint-Zuordnung (fixed_version_id IS NULL) bilden den Backlog. Es gibt zwei Wege, ihn zu sehen:
Backlog-Seite. Neben dem Board-Tab steht im Contextual-Bereich ein Link Backlog. Die Seite listet alle nicht-zugeordneten Tickets mit Subjekt, Tracker, Priorität, Bearbeiter, geschätzten Stunden und einem Sprint-Auswahlfeld pro Zeile. Aus diesem Dropdown einen offenen Sprint wählen → das Ticket wird der Version zugewiesen, die Zeile verschwindet. So lässt sich vorhandene Arbeit en bloc auf kommende Sprints aufteilen, ohne jedes Ticket einzeln zu öffnen. Geschlossene Versionen erscheinen im Dropdown nicht – sie sind Historie, keine Plan-Optionen.
„Noch nicht zugeordnet"-Swimlane. Wenn der Swimlane-Modus auf Bearbeiter steht, erscheint am Board oben eine zusätzliche Reihe Noch nicht zugeordnet mit allen unzugewiesenen Tickets (gelblich hinterlegt). Direkt darunter folgt für jedes Projektmitglied eine eigene Swimlane, auch wenn das Mitglied aktuell keine Tickets hat – jede Person ist damit ein Drop-Target. So lässt sich per Drag & Drop unmittelbar zuweisen, ohne das Ticket öffnen zu müssen (siehe nächster Abschnitt). Diese Swimlane spiegelt nur die Bearbeiter-Zuordnung, nicht die Sprint-Zuordnung — Tickets erscheinen hier auch dann, wenn sie bereits einer Version angehören.
Bei aktivem Swimlane-Modus Bearbeiter setzt jeder Zug einer Karte zwischen Swimlanes nicht nur die Spalte (Status), sondern auch das Bearbeiter-Feld der Ziel-Reihe – in beide Richtungen:
Beide Aktionen laufen über Redmines safe_attributes und new_statuses_allowed_to-Prüfung, also gelten dieselben Workflow-Regeln wie an jeder anderen Stelle in Redmine: ist ein Status- oder Zuweisungswechsel für die Rolle des Benutzers verboten, wird die Karte zurückgesetzt und im Server-Log notiert.
Soll ein Ticket gleichzeitig zugewiesen und in einen Sprint übernommen werden, ist dafür weiterhin die Backlog-Seite (5.8) der direkte Weg – der Drag & Drop am Board ändert immer nur Bearbeiter und Status, nie die Sprint-Zuordnung.
Jeder Kartenzug ist ein Statuswechsel am Ticket – der komplette Änderungsverlauf liegt damit im Ticket-Journal, ohne dass ein separates Log konsultiert oder exportiert werden muss. Swimlane-Gruppenwechsel folgen demselben Weg (das zugehörige Feld wird aktualisiert). Sprint-Zuweisungen über die Backlog-Seite landen ebenfalls als Journaleintrag am Ticket.
Drag & Drop tut nichts / springt zurück. Prüfen, ob der angemeldete Benutzer das Recht Tickets auf dem Kanban-Board bearbeiten hat und ob Redmines Workflow den Wechsel vom Ausgangs- zum Zielstatus für die Rolle des Benutzers erlaubt. Abgelehnte Übergänge lassen die Karte in die Ausgangsspalte zurückspringen.
Eine Spalte fehlt, obwohl ich weiß, dass Tickets in diesem Status existieren. Board-Einstellungen öffnen und prüfen, ob die Spalte als ausgeblendet markiert ist oder Geschlossene Status ausblenden aktiv ist. Für jeden vorhandenen IssueStatus wird automatisch eine Spalte angelegt; ausgeblendete bleiben aber absichtlich unsichtbar.
Keine Karten, obwohl Tickets existieren. Wenn eine gespeicherte Abfrage als Kartenquelle gesetzt ist, die Filter der Abfrage prüfen – Karten außerhalb der Abfrage werden nicht angezeigt. Kartenquelle in den Board-Einstellungen leeren, um zum Standard zurückzukehren (alle Projekttickets).
Performance bei großen Projekten. Das Board rendert jede Karte, die es findet. Für Projekte mit tausenden offenen Tickets eine gespeicherte Abfrage anlegen, die die Menge auf das tatsächlich Relevante begrenzt (z.B. „dieser Sprint" oder „offen und meinem Team zugewiesen"), und diese als Kartenquelle setzen.
Ein neu angelegter Ticketstatus erscheint nicht auf dem Board. Die Spaltenliste wird bei jedem Board-Aufruf abgeglichen. Seite (oder Projekt) neu laden, dann erscheint die neue Spalte am Ende der Sequenz.
Im Sprint-Dropdown taucht eine erwartete Version nicht auf. Das Dropdown zeigt ausschließlich Versionen mit Status offen, die für das Projekt sichtbar sind (eigene Version oder über die Sharing-Einstellung freigegeben). Eine gesperrte oder geschlossene Version verschwindet aus der Auswahl. Status der Version unter Roadmap → Version → Bearbeiten prüfen oder eine neue Version anlegen.
Die Backlog-Seite ist leer, obwohl unzugeordnete Tickets existieren. Die Liste filtert über fixed_version_id IS NULL auf demselben Scope wie das Board (gespeicherte Abfrage und „geschlossene Status ausblenden"). Wenn die Kartenquelle eine Abfrage ist, die alle unzugeordneten Tickets ausschließt, fehlen sie auch im Backlog. Kartenquelle in den Board-Einstellungen leeren und neu prüfen.
Support ist für zwölf Monate ab Kaufdatum enthalten und deckt Fehlermeldungen, Konfigurationsfragen und Kompatibilitätsprobleme ab.
E-Mail: support@atori.de Erstreaktion: werktags innerhalb von 48 Stunden.
Bitte in Supportanfragen angeben:
log/production.log, sofern verfügbar