Version 1.7.0 · 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.7.0.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.7.0 erscheinen, ohne Fehler-Banner.
Ein Redmine-Update ist für das Plugin nur dann unkritisch, wenn die Reihenfolge stimmt. Redmine lädt jedes Plugin beim Start; passt ein Plugin nicht zur neuen Version, startet die ganze Instanz nicht, bis der Plugin-Ordner entfernt ist. Die Daten in den Plugin-Tabellen sind davon nie betroffen.
Regel: Jede Plugin-Version unterstützt die aktuelle und die vorherige Redmine-Linie (derzeit 5.1 und 6). Welche Plugin-Version mit welcher Redmine-Version getestet ist, steht in der Freigabe-Übersicht auf redmine-plugins.atori.de.
Reihenfolge beim Update:
redmine:plugins:migrate, Neustart) und auf der alten Redmine-Version kurz prüfen. Diese Brückenversion läuft auf beiden Redmine-Versionen.bundle exec rake redmine:plugins:migrate RAILS_ENV=production und Neustart.Fallweg, wenn keine Brückenversion existiert (etwa weil die neue Redmine-Version ein neueres Ruby verlangt):
cd /pfad/zu/redmine
mv plugins/at_kanbanboard ../at_kanbanboard.alt # Ordner beiseitelegen, NICHT migrieren
# Redmine aktualisieren
# neue Plugin-Version nach plugins/at_kanbanboard entpacken
bundle exec rake redmine:plugins:migrate NAME=at_kanbanboard RAILS_ENV=production
# Redmine neu startenDie Plugin-Tabellen bleiben dabei unverändert in der Datenbank; die neue Plugin-Version hebt das Schema mit ihren eigenen Migrationen an.
> Nie VERSION=0 als Teil eines Updates. Die Rückwärtsmigration auf > Version 0 löscht die Plugin-Tabellen und damit alle Daten des Plugins. > Sie gehört ausschließlich zur endgültigen Deinstallation (siehe unten).
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.
Abgelehnte Verschiebung. Lässt der Workflow den Statuswechsel nicht zu oder würde der Zug das WIP-Limit der Zielspalte überschreiten, wird der Zug abgelehnt: Die Karte springt in die Ausgangsspalte zurück und oben im Board erscheint eine dauerhaft sichtbare Meldung mit dem Grund. Die Seite wird dabei nicht neu geladen; die Meldung bleibt stehen, bis sie über das Schließen-Symbol (×) weggeklickt wird.
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.
Zeilen zu- und aufklappen. Jede Swimlane trägt links einen Pfeil zum Zu- und Aufklappen; zugeklappt bleibt nur die Beschriftung mit der Anzahl der Karten sichtbar. Alle zuklappen / Alle aufklappen in der Kopfzeile schaltet alle Zeilen auf einmal. Der Zustand wird pro Projekt im Browser gespeichert und beim nächsten Aufruf wiederhergestellt; er ist nur eine Anzeigeeinstellung des jeweiligen Benutzers. In eine zugeklappte Zeile lassen sich keine Karten ziehen – erst aufklappen, dann ablegen.
Pro Spalte lässt sich eine positive Ganzzahl als Grenze setzen. Übersteigt die Kartenanzahl das Limit, markiert der Spaltenkopf die Spalte. Ein Drag-&-Drop-Zug, der die Zielspalte über ihr Limit bringen würde, wird abgelehnt: Die Karte springt zurück und es erscheint eine dauerhafte Meldung am Board (siehe 5.2). Ein bereits per Filter/Direktbuchung über dem Limit liegender Spaltenstand wird hingegen nur markiert, nicht nachträglich erzwungen.
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; der genaue Grund (verbotener Übergang oder erreichtes WIP-Limit) steht in der Meldung oben am Board. Bleibt sie unbeachtet, deutet ein sofortiges Zurückspringen ohne Meldung auf das fehlende Recht hin.
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