In diesem Beitrag erfährst Du wie Scrum Master, Teams und das Management das Reporting Plugin für ihre Sprint- und Versionsplanung nutzen können.

Sprint = Version: Redmine kann das bereits

Bevor wir in die Praxis gehen, eine wichtige Einordnung: Das Reporting Plugin führt keine eigene, separate Sprint-Entität ein. Stattdessen nutzt es die Redmine-Versionen als Sprints - und erweitert diese einfach um das notwendige Enddatum.

Warum? Redmine-Versionen bringen alles mit, was ein Sprint braucht:

• Start- und Enddatum - hier hinterlegst du das Zeitfenster deiner Iteration
• Freigabe über Projekte hinweg - ein Sprint kann bei Bedarf in unterschiedlichen Projekten gemeinsam genutzt werden
• Automatische Integration - Versionen sind relevant für den Burndown Chart, die Roadmap und Fortschrittsanzeige und das ohne Zusatzaufwand

Du musst also kein zweites Konzept lernen und keine parallele Datenstruktur pflegen. Ein “Backlog” ist einfach ein eigener Status, oder eine Version, in der du ungeplante Tickets sammelst. Ein “Sprint” ist eine Version mit dem von dir definierten Zeitfenster. Das Reporting Plugin ergänzt genau die Werkzeuge, die dir im Redmine-Standard fehlen: das visuelle Planungsboard und die grafische Auswertung (Burndown-Chart).

Für Scrum Master und Projektleiter: Sprint Planning per Drag & Drop

Die Situation: Sprint-Planning-Meeting. Vor dir liegen 60 Tickets im Backlog, und in den nächsten 45 Minuten soll daraus ein voller Sprint werden. In der klassischen Ticketliste hieße das: jedes Ticket öffnen, Zielversion setzen, speichern, zurück zur Liste. Bei 20 einzuplanenden Tickets ist das Meeting vorbei, bevor die Planung fertig ist.

Die Lösung: Du öffnest das Taskboard des Reporting-Plugins und gruppierst es nach Version. Jetzt siehst du deine Versionen als Bereiche (Swimlanes): den Backlog, den aktuellen und den nächsten Sprint. Ziehst du ein Ticket aus dem Backlog in die Sprint-Version, passiert beides in einer einzigen Aktion:

• Zielversion wird gesetzt - das Ticket gehört jetzt zum Sprint
• Status wird geändert - z.B. von “Backlog” zu “Sprint bereit”, wenn du gleichzeitig die Statusspalte wechselst

Tipp: Halte beim Ziehen die Shift-Taste, es öffnet sich ein Kommentarfeld - so hältst du direkt fest, warum ein Ticket in diesen Sprint kommt. Und weil das Board alle Workflow-Regeln und Berechtigungen respektiert, kannst du keine ungültigen Übergänge erzeugen: Ein nicht erlaubtes Ticket springt zurück und zeigt eine entsprechende Meldung an.

Das Ergebnis: Das Team sieht in Echtzeit, wie sich der Sprint füllt, und diskutiert über Inhalte statt über Formalitäten. Für ganze Ticket-Pakete nutzt du zusätzlich die Bulk-Edit Aktionen (relevante Tickets auswählen, Rechtsklick, Redmine-Bulk-Edit) und weist mehreren Tickets auf einmal die gewünschte Version zu.

Für Teams: Den Sprint abarbeiten

Die Situation: Der Sprint läuft. Im Daily Scrum stellen sich die Team-Mitglieder ihre üblichen Fragen: Was wurde gestern gemacht? Was steht heute an? Gibt es ein Problem? Und wer hat Kapazität für das nächste Ticket? Ein Blick in eine lange Liste beantwortet keine dieser Fragen schnell.

Die Lösung: Ihr filtert das Board auf die aktuelle Sprint-Version und gruppiert nach Zugewiesen an. Jetzt hat jedes Teammitglied seine eigene Zeile über alle Statusspalten hinweg:

• Lastverteilung auf einen Blick: Wer 6 Tickets in “In Arbeit” hat und wer keins, ist sofort erkennbar. Zeit zum Umverteilen.
• Zuweisung in Sekunden: Über die Avatar Bar ziehst du einen Kollegen direkt auf ein unbesetztes Ticket - kein Ticket öffnen, kein Dropdown. Das System merkt sich häufig genutzte Personen automatisch.
• Engpässe sichtbar machen: Stauen sich Tickets in “Review”, während “In Arbeit” leer läuft, habt ihr ein Prozessproblem im Sprint - nicht erst am Sprint-Ende, sondern jetzt.

Farbliche Kennzeichnung (z.B. nach Tracker: Bugs rot, Features blau) macht relevante Unterschiede zusätzlich sofort sichtbar. Und wer im Team lieber ein reines Kanban ohne feste Sprints fährt, nutzt dasselbe Board einfach ohne Versionsgruppierung weiter. Zusätzlich kann man auch mit einem WiP-Limit arbeiten.

Das Ergebnis: Das Daily dauert wieder 15 Minuten. Jeder pflegt seinen Status per Drag & Drop selbst, die Diskussion konzentriert sich auf echte Blocker, und niemand fragt mehr “Wo steht mein Ticket eigentlich?”.

Für Management und Admins: Fortschritt und Portfolio

Die Situation: Du verantwortest mehrere parallele Teams und Releases. Die Geschäftsführung will wissen: Schaffen wir den Sprint? Wo überschneiden sich Releases? Und läuft ein Team seinem Ziel hinterher, bevor es zu spät ist?

Die Lösung: Weil deine Sprints echte Redmine-Versionen sind, kannst du sie direkt für die grafischen Auswertungen des Reporting Plugins nutzen.

Burndown Chart für den einzelnen Sprint:

Der Burndown Chart zeigt für jede Version drei Linien: die theoretische Ideallinie, die tatsächlich offenen Tickets (bzw. Stunden) und alle Tickets inklusive neu hinzugekommener. Liegt die Ist-Linie über der Ideallinie, hängt das Team hinterher - und du siehst es früh genug, um Ressourcen zu verschieben oder den Scope anzupassen. Am praktischsten als Dashboard-Block direkt auf der Projektübersicht.

Roadmap für das Portfolio:

Die Roadmap-Ansicht stellt deine Versionen zeitbasiert auf einer Achse dar. Über die Versionsliste erkennst du sofort, wie sich Sprints und Releases über die Teams verteilen und wo kritische Phasen zusammenfallen.

Sprints teamübergreifend teilen: Weil Sprints auf Versionen basieren, kannst du sie über die Standard-Freigabe teilen - mit Unterprojekten, der Projekthierarchie, dem Projektbaum oder allen Projekten. Mehrere Teams planen so denselben Release gemeinsam, und die projektübergreifende Taskboard-Ansicht bündelt alle beteiligten Tickets an einem Ort.

Das Ergebnis: Du präsentierst dem Management keine vagen Einschätzungen, sondern konkrete Verläufe: “Sprint 14 in Team A liegt seit Tag 4 über der Ideallinie, hier steuern wir gegen. Team B ist im Plan.”

Die gespeicherte Abfrage

Egal ob Sprint-Planung, tägliche Team-Arbeit oder Fortschrittskontrolle - die eigentliche Stärke liegt in den benutzerdefinierten Abfragen, die Redmine bereit stellt. Du richtest eine Baord-Ansicht einmal ein und speicherst Filter, Gruppierung, Spaltenauswahl und Farbschema als Teil der Abfrage. Danach steht sie dir und deinem Team jederzeit per Klick zur Verfügung. Und das Tolle daran -> du hast immer die üblichen Ticketfilter und Spalten zur Auswahl.

Bewährt haben sich zum Beispiel:

• “Sprint Planning” - Board gruppiert nach Version, für das Planungsmeeting
• “Unser Sprint” - Board gefiltert auf die aktive Version, gruppiert nach Benutzern, für das Daily Scrum Meeting
• “Release-Fortschritt” - Burndown-Block auf dem Projekt-Dashboard, für den Management-Blick

So wird aus einzelnen Funktionen ein durchgängiger agiler Arbeitsablauf.

So richtest du deine Sprint-Planung ein

1. Versionen anlegen: Erstelle unter Projekt-Einstellungen / Versionen deine Sprints mit Start- und Enddatum. Eine Version ohne Datum kann alternativ als Backlog dienen.
2. Board öffnen: Gehe in den Bereich Tickets, öffne die Optionen und wähle bei Ergebnisse anzeigen als die Option Board.
3. Nach Zielversion gruppieren: Unter Gruppiere Ergebnisse nach wählst du Zielversion - jetzt kannst du Tickets zwischen Backlog und Sprints ziehen.
4. Ansicht speichern: Sichere die Konfiguration als benutzerdefinierte Abfrage, optional geteilt mit deinem Team.
5. Fortschritt aktivieren: Ein Administrator aktiviert den Burndown Chart unter Plugins / Redmine Reporting / Allgemein (Option Burndown-Chart für Versionen anzeigen).

Voraussetzungen: Datenpflege lohnt sich: Nur mit gepflegten Start- und Enddaten entfalten Burndown und Roadmap ihren vollen Nutzen. Die Tickets selbst benötigen keine Datumsangabe, die wird automatisch von der zugewiesenen Version übernommen. Das hat den Vorteil, dass man einfach nur die Versionszuweisung ändern muss und die Datumsangaben passen sich automatisch im Ticket an.

Fazit

Das Reporting-Taskboard macht Redmine zu einem praxistauglichen Sprint-Werkzeug: Planung, tägliche Arbeit und Fortschrittskontrolle laufen an einem Ort, ohne neue Methodik und ohne Toolwechsel. Die Boardansicht ist nämlich einfach nur eine andere Darstellung der Ticketliste.

Es ist kein 100% Ersatz für ein dediziertes Scrum-Tool: Wenn dein Team zwingend eines der folgenden Dinge braucht, ist der aktuelle Funktionsumfang nicht ausreichend:

• Backlog-Priorisierung per Drag & Drop - im Board bestimmen Filter und Sortierung die Reihenfolge, ein manuelles Ranking geht nur über ein Positions-Feld (ist als Erweiterung angedacht).
• Getrennte Sprint- und Release-Ebenen - ein Ticket gehört zu genau einer Version, also entweder Sprint oder Release, nicht beidem gleichzeitig.
• Story Points und Velocity - Schätzpunkte lassen sich als benutzerdefiniertes Feld abbilden, einen nativen Velocity-Chart gibt es aber nicht.

Die meisten Teams, die nicht strikt agil arbeiten, Redmine Reporting ohnehin installiert haben und den pragmatischen Ansatz bevorzugen, werden mit dem Funktionsumfang im Alltag jedoch gut zurechtkommen.

Alle Informationen zu unseren Erweiterungen für Redmine gibt es auf der Produktseite. Das kostenpflichtige Reporting Plugin gibt es einzeln oder als Teil unseres Business-Class Bundle, sowie dem Enterprise+ Bundle. Die hier beschriebene Funktion kann in unserer Online-Demo ausgiebig getestet werden.

Weiterführende Infos

• Redmine Reporting Plugin
• Task Board Ansicht
• Burndown Charts
• Redmine Online Demo
• Plugin Features

Die Version 4.5.0 unserer Redmine Plugins enthält neue Funktionen, Verbesserungen und Fehlerbehebungen. Die wichtigsten Änderungen sind das überarbeitete Task Board mit Swimlanes und WIP-Limits im Reporting Plugin, neue E-Rechnungs-Belegarten (Gutschriften und Korrekturrechnungen) sowie wählbare Zahlungsarten im ServiceDesk Plugin und neue HRM-Werkzeuge für unser AI Plugin. Hinzu kommen kleinere Änderungen, Performance-Optimierungen und Sicherheits-Updates über alle Plugins hinweg.

Wichtiger Hinweis zur Redmine-Kompatibilität: Version 4.5.0 ist die letzte Version, die Redmine 6.1x unterstützt. Ein Update auf Redmine 7 wird von dieser Version noch nicht unterstützt - die Kompatibilität mit Redmine 7 ist für die nächste Plugin-Version geplant.

Zwei neue Plugins verfügbar

Mit dieser Version stehen zwei neue Plugins zur Verfügung:

• Neu: Redmine Templates - Vorlagen für Tickets, Notizen, Projekte und Wiki-Seiten. Das Plugin ist der Nachfolger der bisherigen ServiceDesk-Textbausteine (Canned Responses) und lässt sich plugin-übergreifend nutzen.
• Neu: Redmine Timesheet - Erfassung und Auswertung von Aufwänden in einer Timesheet-Ansicht.

Redmine Automation

Regeln lassen sich jetzt so konfigurieren, dass sie Änderungen vornehmen, ohne die üblichen E-Mail-Benachrichtigungen auszulösen. Das ist nützlich für automatische Massenanpassungen, bei denen die Beteiligten keine Benachrichtigungen erhalten sollen.

• Neu: Benachrichtigungs-Unterdrückung pro Regel - eine Regel kann Änderungen durchführen, ohne die üblichen E-Mail-Benachrichtigungen auszulösen. Die Änderung bleibt in der Ticket-Historie sichtbar, explizite “E-Mail senden”-Aktionen werden weiterhin zugestellt.
• Neu: Neue Variablen für die relative Woche und das relative Jahr (z.B. nächste Woche, Vorjahr) in Aktionen und Bedingungen.
• Neu: Einklappbarer Variablen-Spickzettel (“Variablen anzeigen”) in allen Formularen, die Automation-Variablen unterstützen.
• Verbesserung: Tickets und Projekte aus Vorlagen-Projekten lösen keine Event-Regeln, Zeitpläne oder Erinnerungs-Mails mehr aus.
• Verbesserung: Bedingungen mit für den Auslöser ungültigen Filter-Feldern werden beim Speichern abgelehnt bzw. zur Laufzeit sicher übersprungen und im Reporting-Log vermerkt.

Redmine DB

• Neu: Auto-Mapping beim CSV-Import.
• Neu: Aktionen-Menü auf der Detailseite eines Eintrags mit neuer Aktion “Link kopieren”.
• Neu: DB-Einträge werden im Reporting-Log erfasst und stehen dort als Query- und Datei-Container zur Verfügung (bei installiertem Reporting Plugin).
• Verbesserung: Benutzer-Felder nutzen jetzt das zentrale Feldformat mit der neuen Auswahl “Alle aktiven Benutzer” (schließt gesperrte Logins aus). Bestehende Felder werden automatisch migriert.
• Verbesserung: Diagramm-Blöcke laden bei Bedarf nach (Lazy-Loading).

Redmine DevOps

• Verbesserung: Überarbeitete Hetzner-Server-Detailansicht - Serverstatus als farbiges Badge, Stadt als Kurzform mit Standort-Tooltip.
• Verbesserung: Das Changeset-Matrix-Diagramm im Dashboard lädt bei Bedarf nach (Lazy-Loading).
• Fehlerbehebung: Erkennung veralteter Hetzner-Servertypen korrigiert und Repository-Webhook-Auslösung stabilisiert.

Redmine HRM

Mit Version 4.5.0 stellt das HRM Plugin neue Werkzeuge für unser AI Plugin bereit: Sofern das AI Plugin installiert ist, kann die KI darüber Benutzer suchen sowie Anwesenheiten protokollieren und durchsuchen. Die KI-Funktion selbst stammt aus dem AI Plugin - das HRM Plugin liefert die passenden HRM-spezifischen Werkzeuge dazu. Zusätzlich lassen sich Feiertage jetzt im iCal-Format importieren und exportieren. Das erleichtert die manuelle Pflege.

• Neu: Neue HRM-Werkzeuge für unser AI Plugin - bei installiertem AI Plugin kann die KI darüber Benutzer suchen sowie Anwesenheiten protokollieren und durchsuchen.
• Neu: iCal-Import und -Export für Feiertage (eintägige Feiertage werden importiert, mehrtägige Bereiche wie Schulferien werden bewusst übersprungen).
• Neu: Neuer Ticket-Filter “beteiligter Benutzer”, um zuverlässig alle Tickets zu finden, an denen ein Benutzer beteiligt ist.
• Neu: Readonly-Timesheet im Aufwands-Tab des Benutzerprofils (berücksichtigt die Einstellung zum Wochenbeginn).
• Neu: Warndialog beim Wechsel eines Benutzers von intern auf extern.
• Fehlerbehebung: Sommer-/Winterzeit-Fehler behoben - Anwesenheitszeiten werden als absolute Zeitstempel gespeichert.
• Verbesserung: Kompatibilität mit dem aktuellen Redmine master (Rails 8.1).

Redmine Passwords

• Neu: Auto-Mapping beim CSV-Import.
• Neu: Aktionen-Menü auf der Detailseite eines Passworts mit neuer Aktion “Link kopieren”.
• Neu: Passwörter werden im Reporting-Log erfasst und stehen als Query zur Verfügung (bei installiertem Reporting Plugin).
• Verbesserung: Reine Notiz-Änderungen aktualisieren jetzt das Änderungsdatum des Passworts.
• Verbesserung: Das Matrix-Diagramm lädt bei Bedarf nach (Lazy-Loading).

Redmine Reporting

Die zentrale Änderung der Version 4.5.0: Das Task Board wurde grundlegend überarbeitet. Es ist jetzt eine durchgehende Matrix mit echten Swimlanes, fixiertem Spaltenkopf, zweiachsigem Drag & Drop und WIP-Limits pro Status-Spalte. Karten lassen sich direkt inline bearbeiten und kommentieren.

Überarbeitetes Task Board mit Swimlanes und WIP-Limits

• Neu: Task Board Revision - durchgehende Matrix mit echten Swimlanes, WIP-Limits pro Status-Spalte, Inline-Bearbeitung und Kommentaren direkt auf den Karten sowie Drag & Drop über beide Achsen.
• Neu: Vorlagen aus dem Templates Plugin (Ticket, Notiz, Projekt, Wiki) werden im Reporting-Log erfasst und verlinken auf die jeweilige Vorlagen-Seite.
• Verbesserung: Modernisierte Burndown-Charts mit Verlaufsfüllung, Farben aus dem Farbschema und bedingter Heute-Markierung.
• Verbesserung: Modernisiertes Design der Zählerboxen (Counter Boxes) mit kontrastbewussten Wertefarben.
• Verbesserung: Aktualisierung auf Mermaid v11.16.x.
• Verbesserung: Deutlich optimierte Sichtbarkeitsprüfung für Zeiteinträge (bis zu ~97% kleinere SQL-Bedingung bei Benutzern mit vielen Projektmitgliedschaften).
• Fehlerbehebung: Zeitliche Angaben (z.B. “vor 2 Stunden”) nutzen in Zeit-Spalten jetzt die Benutzer-Zeitzone statt UTC.

Modernisiertes Design der Zählerboxen mit kontrastbewussten Wertefarben

Redmine ServiceDesk

Mit Version 4.5.0 wurde die E-Rechnung erweitert: Gutschriften und Korrekturrechnungen sind jetzt eigene Belegarten mit getrennten Nummernkreisen. Pro Rechnung lässt sich die Zahlungsart (Überweisung, PayPal, SEPA-Lastschrift, Verrechnung) festlegen, die Zahlungsweg und E-Rechnung entsprechend steuert.

• Neu: Gutschriften und Korrekturrechnungen als eigene Belegarten mit getrennten Nummernkreisen, Inhaltssperre und E-Rechnungs-Referenzen.
• Neu: Zahlungsart je Rechnung (Überweisung, PayPal, SEPA-Lastschrift, Verrechnung) - steuert die Zahlungsangaben in E-Rechnung (XML) und PDF, inklusive SEPA-Mandatsverwaltung je Kontakt.
• Neu: Benutzerdefinierte Felder vom Format “Benutzer” erhalten eine wählbare Benutzer-Auswahl (Alle Benutzer, Alle aktiven Benutzer, aus Projekt oder nach Rolle) - so lassen sich z.B. Kunden-Logins direkt am Kontakt hinterlegen.
• Neu: Auto-Mapping beim CSV-Import und Unterstützung für Ticket-Tags.
• Neu: Canned Responses wurden entfernt und durch das Templates Plugin ersetzt (bestehende Textbausteine werden bei installiertem Templates Plugin automatisch migriert).
• Verbesserung: Rechnungs-Zahlungseingänge werden als nicht editierbare History-Einträge dokumentiert.

Redmine WikiGuide

• Neu: Wiki-Seiten können benutzerdefinierte Felder vom Format “Benutzer” tragen, mit wählbarem Benutzer-Umfang.
• Fehlerbehebung: Interner Fehler beim Ändern von Wiki-Seiten-Attributen behoben.

Die oben genannten Produkte sind alle Teil des Enterprise+ Bundles.

Fazit

Die Version 4.5.0 umfasst Änderungen in allen unseren Plugins. Die relevanten Neuerungen sind das überarbeitete Task Board im Reporting Plugin, die erweiterten E-Rechnungs- und Zahlungsfunktionen im ServiceDesk Plugin und die neuen HRM-Werkzeuge für unser AI Plugin. Dazu kommen die beiden neuen Plugins Templates und Timesheet sowie plugin-übergreifend Performance-Optimierungen, Sicherheits-Updates und kleinere Korrekturen.

Bitte beachte folgendes: Version 4.5.0 ist die letzte Version für Redmine 6.1x. Den Support für Redmine 7 planen wir für die nächste Plugin-Version. Für Dich genau der passende Zeitpunkt, um dein nächstes größeres Redmine-Update vorzubereiten.

Redmine Update vom Profi

Kunden deren Redmine wir betreuen, oder die ein Redmine Hosting Paket bei uns verwenden müssen sich keine Gedanken bezüglich des Updates auf die neuste Plugin-Version machen. Das übernehmen wir im Zuge unseres regulären Hostings.

Alle Informationen zu unseren Redmine-Erweiterungen gibt es auf der Produktseite. Die Plugins gibt es einzeln oder im Bundle. Die Nutzung ist nur gemäß unserer Mindestanforderungen möglich. Alternativ besteht die Möglichkeit unser Managed Applikation Hosting für Redmine zu buchen (InHouse oder Cloud). In unserer frei zugänglichen Online-Demo können die Funktionalitäten der aktuellen Plugin-Version getestet werden. Für Fragen die unsere Produktseiten, FAQs oder Online-Trainings nicht beantworten, stehen wir gerne zur Verfügung. Schreib uns eine Nachricht.

Weiterführende Infos

• Plugin Update Informationen
• Redmine Online-Demo

Die vollständige Changelog findest Du wie immer auf Redmine.org.

Hinweis: Unsere Plugins bis einschließlich Version 4.5.0 unterstützen Redmine 7.0.0 noch nicht. Die Unterstützung für Redmine 7 ist voraussichtlich ab Plugin-Version 4.6.0 vorgesehen. Vor einem Update solltest Du wie üblich immer zuerst die Mindestvoraussetzungen prüfen.

Funktionen, die Deinen Arbeitsalltag erleichtern werden

• Überarbeiteter Header: Der Seitenkopf erhält eine neue Navigationsleiste (Feature #43937).
• Angepasstes Design: Mit Open Color werden die Farben vereinheitlicht. Dazu kommen veränderte Abstände und Rahmen in der gesamten Oberfläche (Feature #43256).
• Dateityp-Symbole: Anhänge zeigen nun passende Datei-Icons statt der bisherigen Büroklammer (Feature #43797).
• Tabellen aus Tabellenkalkulationen einfügen: Inhalte aus Excel oder LibreOffice Calc lassen sich direkt als CommonMark- oder Textile-Tabelle in Textfelder einfügen (Feature #43950).
• Vorschau für PDF- und Office-Dateien: Anhänge können angezeigt werden, ohne sie vorher herunterzuladen (Feature #22483, #8959).
• Wiki als ZIP exportieren: Alle Wiki-Seiten eines Projekts lassen sich gesammelt als ZIP-Archiv herunterladen (Feature #43978).

Hinweis: Open Color ist vor allem für Theme-Entwickler interessant. Da die Farben zentral als CSS-Variablen gepflegt werden, lässt sich ein eigenes Farbschema an einer Stelle anpassen, statt einzelne Werte quer durch die CSS zu überschreiben. Das schafft zugleich die technische Grundlage für einen späteren Dark Mode, der dann im Wesentlichen nur einen zweiten Satz Variablenwerte benötigen wird.

Relevante Einstellungen für Projektleiter und Administratoren

Die folgenden Neuerungen betreffen weniger die tägliche Ticketbearbeitung als die Steuerung dahinter: Sie sind daher mehr für Administratoren und Projektleiter relevant. Weil sie dabei helfen Zuständigkeiten und Prozesse sauber zu trennen und Zugriffe nachvollziehbar zu machen.

• Bearbeiter automatisch beobachten: Wer eine Aufgabe zugewiesen bekommt, kann optional automatisch als Beobachter hinzugefügt werden (Feature #2716).
• Sortierung der Bearbeiter-Auswahl: Die Reihenfolge im Zuweisen-Dropdown ist konfigurierbar, inklusive Gruppierung nach Gruppen (Feature #43996, #44015).
• Nutzung von API- und Atom-Schlüsseln nachvollziehen: Die letzte Verwendung von Zugriffsschlüsseln wird protokolliert (Feature #43938).

Ein paar technische Neuerungen

• Update auf Rails 8 (Feature #43205) und Unterstützung für Ruby 4.0 (Feature #43650).
• Webhooks: Redmine kann Webhooks auslösen und externe Systeme bei Ereignissen benachrichtigen (Feature #29664).
• Geänderte HTML-Verarbeitung: Die Textaufbereitung wechselt von html-pipeline zu Loofah (Feature #42737, #43643).

Performance und Bedienung

• Schnellere Darstellung bei der Erwähnung von Nutzern (@login) auf großen Instanzen (Defect #43838).
• Bessere Performance beim Speichern von Workflows (Feature #43957).

Fazit

Ein technisches Major-Upgrade ist kein Feature, das man “benutzt” - es ist eher die Voraussetzung dafür, dass alles andere sicher und langfristig weiterläuft. Unterm Strich bringt Redmine 7.0.0 zwei Dinge zusammen: viele kleine Verbesserungen für ein angenehmeres Arbeiten und mit Rails 8, Ruby 4.0 und Webhooks einen spürbaren technischen Sprung im Vergleich zur Vorgängerreihe (Redmine 6.x).

Hinweis für Hosting-Kunden: Für Kunden im Redmine Managed Application Hosting übernehmen wir das Update. Wir testen neue Versionen wie Redmine 7.0.0 vorab, insbesondere auf Kompatibilität mit allen eingesetzten Plugins, und stellen sie erst danach bereit. Eine eigene technische Umsetzung ist nicht erforderlich. Wir werden unsere Plugins schnell auf die neueste Version anpassen, müssen aber auch sicher stellen, dass eventuelle Drittanbieter-Plugins ebenfalls schon damit funktionieren. Sobald das der Fall ist, spricht nichts gegen ein Update auf die 7er Version.

Weiterführende Infos

• AlphaNodes Redmine Plugins
• Redmine Online-Demo
• Redmine Hosting

Doch wo und wie verwaltet man diese Dokumente am besten? Viele Teams nutzen bereits Redmine als Projektmanagement-Tool - und wissen oft nicht, dass das integrierte Wiki ideal für die Verwaltung von ADRs geeignet ist.

Warum das Redmine-Wiki?

1. Alles an einem Ort Redmine ist in vielen Projektteams bereits im Einsatz. Das Wiki ist direkt integriert sodass du nur das Modul im Projekt aktivieren musst, um es zu nutzen. Alle ADRs liegen dann zentral in diesem Projektwiki und sind mit anderen Projektinformationen verknüpft.
2. Einfache Strukturierung Mit dem Redmine-Wiki kannst du für jedes ADR eine eigene Seite anlegen und diese verlinken. Eine einfache Hauptseite mit einer Liste aller ADRs reicht bereits aus, um den Überblick zu behalten. Die Struktur bleibt flexibel und passt sich deinen Anforderungen an.
3. Versionierung und Historie Jede Änderung an einer Wiki-Seite wird automatisch protokolliert. So siehst du immer, wer wann was geändert hat - ein entscheidender Vorteil, wenn du nachvollziehen möchtest, warum eine bestimmte Entscheidung getroffen oder später angepasst wurde.
4. Kollaboration im Team Das Redmine-Wiki ermöglicht es allen Teammitgliedern, ADRs zu lesen, zu kommentieren und bei Bedarf zu aktualisieren. Durch die Rechteverwaltung kannst du steuern, wer Änderungen vornehmen darf und wer nur lesen darf.

Beispiel aus der Praxis

Ein typisches ADR im Redmine-Wiki könnte so aussehen:

## ADR-001: Warum nutzen wir Docker für die Bereitstellung?

* **Status:** Akzeptiert (2025-06-01)
* **Kontext:** Wir benötigen eine flexible, reproduzierbare Umgebung für unsere Microservices.
* **Optionen:** Virtuelle Maschinen, Docker, Kubernetes
* **Entscheidung:** Docker
* **Begründung:** Docker bietet eine einfache Containerisierung, schnelle Bereitstellung und gute Integration in unsere bestehende Infrastruktur.
* **Konsequenzen:** Das Team muss Docker lernen, aber langfristig profitieren wir von der Flexibilität.

Die Syntax der Redmine Wiki richtet sich nach der global eingerichteten Textformatierung von Redmine (Textile → veraltet, CommonMark Markdown (GitHub Floared) → empfohlen)

Das Redmine-Wiki ist eine praktische, kostengünstige Lösung für die Verwaltung von ADRs - besonders für Teams, die Redmine bereits nutzen. Es bietet alles, was du für eine klare, nachvollziehbare und kollaborative Dokumentation brauchst: zentrale Ablage, Versionierung, einfache Bearbeitung.

Und wem das nicht ausreicht oder wer Wert auf umfangreiche Suchfunktionen legt, dem bietet das Redmine Wiki Guide Plugin weitere nützliche Funktionen um dich bei der Dokumentation der ADRs zu unterstützen.

Zusätzliche Funktionen durch Wiki Guide Plugin für Redmine

• Mit intelligenter LiveSearch findest Du Inhalte noch schneller als über die globale Redmine Suche.
• Regex-Operatoren in den Filtern der Wiki-Liste helfen beim gezielteren Aufspüren spezieller Informationen im Inhalt oder Titel.
• TAGs für Wiki-Seiten sorgen für eine klare Kategorisierung von ADRs.
• Mehrstufige Freigabeworkflows stellen sicher, dass nur geprüfte Inhalte veröffentlicht werden.
• Lesebestätigungen garantieren, dass wichtige Dokumente wirklich bei allen ankommen.
• Automatische Listen zeigen verwaiste oder veraltete Seiten auf.
• Die Wiki Liste erlaubt die Filterung nach relevanten Metriken wie beispielsweise Autor, Beobachter, Vertraulich, Aktualisiert, Status etc.
• und noch einiges mehr…

Probier es aus und bringe mehr Transparenz in deine Architektur-Entscheidungen!

Alle Informationen zu unseren Erweiterungen für Redmine gibt es auf der Produktseite. Kunden, deren Redmine den Mindestanforderungen nicht entspricht oder die lieber jemanden für die Installation und regelmäßige Pflege ihrer Redmine-Instanz beauftragen wollen, haben alternativ die Möglichkeit unser Managed Applikation Hosting für Redmine zu buchen. Hier ist das Plugin bereits Teil unseres Hosting Angebots. Die Funktionalität kann in unserer Online-Demo ausgiebig getestet werden.

Weiterführende Infos

• Redmine Wiki Guide Plugin
• AlphaNodes Redmine Plugins
• Redmine Online-Demo

Dieser Beitrag richtet sich an Redmine-Administratoren und Projektverantwortliche, die ihr Rechtesystem optimieren wollen (tiefes technisches Wissen brauchst du dafür nicht). Wir erklären, wie das Berechtigungssystem aufgebaut ist, und geben dir eine kompakte Liste an Do’s und Don’ts für ein nachvollziehbares, zukunftsicheres Konzept.

Warum ist das für Redmine-Administratoren wichtig?

Ein sauberes Rollenkonzept hält dein Redmine übersichtlich - auch wenn neue Projekte und Leute dazukommen. Unklare Rechte kosten dich Zeit bei jeder Rückfrage. Und sie sind ein Sicherheitsthema: Wenn jemand mehr sieht oder darf als gedacht, fällt das oft erst spät auf. Wer die Rechte einmal bewusst aufsetzt und kurz dokumentiert, spart sich später das Rätselraten vom Anfang.

Die zwei Ebenen, an denen die meisten scheitern

Redmine verteilt Rechte nicht an einzelne Personen, sondern an Rollen. Eine Rolle wird einmal zentral unter Administration -> Rollen und Rechte definiert. Sie ist im Kern eine Sammlung von Berechtigungen. Eine Person bekommt diese Rolle anschließend pro Projekt zugewiesen, und damit greifen deren Rechte. Wichtig ist die Frage, wo ein Recht überhaupt wirkt:

• Die meisten Berechtigungen werden pro Projekt ausgewertet. Sie steuern, was eine Rolle innerhalb eines bestimmten Projekts darf: Tickets sehen, Tickets bearbeiten, Wiki pflegen, Dateien hochladen und so weiter. Sie greifen nur in den Projekten, in denen der Person die Rolle zugewiesen ist. Dieselbe Person kann also in Projekt A mehr dürfen als in Projekt B - je nach dort zugewiesener Rolle.

• Nur wenige Berechtigungen gelten systemweit (global). Sie sind an kein einzelnes Projekt gebunden. Das bekannteste Beispiel ist Projekt anlegen: Wer dieses Recht über seine Rolle hat, darf neue Projekte erstellen, unabhängig von einem bestehenden Projekt. Das Verwalten eines bestehenden Projekts - also bearbeiten, schließen oder Mitglieder verwalten - ist dagegen projektbezogen: Diese Rechte vergibst du pro Rolle, und sie gelten nur in den Projekten, in denen jemand diese Rolle hat. In der Praxis steckt das oft in der Manager-Rolle. Wer ein Projekt anlegt, bekommt darin außerdem automatisch eine festgelegte Rolle - in vielen Installationen Manager (einstellbar in den Projekt-Einstellungen) - und darf sein Projekt deshalb anschließend auch verwalten.

Eine gute Gesamtübersicht liefert dir der Berechtigungsbericht unter Administration -> Rollen und Rechte. Dort siehst du alle Rollen und ihre Rechte als Matrix nebeneinander und erkennst auf einen Blick, wo eine Rolle mehr oder weniger darf als gedacht.

Der dritte, oft übersehene Punkt:

• Ein Recht greift nur, wenn das zugehörige Modul im Projekt aktiviert ist. Wer das Wiki-Modul im Projekt deaktiviert hat, dem nützt das Wiki-Recht nichts. Genau hier entsteht die häufigste Verwirrung - das Recht ist gesetzt, aber die Funktion taucht nicht auf, weil das Modul fehlt.

Sonderfall Nichtmitglied und Anonymous: Diese beiden eingebauten Rollen sorgen besonders oft für Unsicherheit, weil sie sich anders verhalten als normale Projektrollen. Du weist sie niemandem manuell zu, sie greifen automatisch und nur in öffentlichen Projekten. Nichtmitglied gilt für angemeldete Benutzer, die im Projekt kein Mitglied sind; das kann auch intern relevant sein, wenn ein Projekt für alle Mitarbeitenden sichtbar sein soll. Anonymous gilt dagegen für gar nicht angemeldete Besucher und greift nur, wenn anonymer Zugriff überhaupt erlaubt ist (Einstellung Authentifizierung erforderlich deaktiviert). In einem internen, datenschutzbewussten Redmine ist das meist nicht so - dann hat die Anonymous-Rolle gar keine Wirkung und ist eher ein Thema für öffentlich zugängliche Redmines. Sei bei beiden trotzdem sparsam: Was du hier erlaubst, gilt für jeden.

Do’s

• Arbeite nach dem Least-Privilege-Prinzip. Fang lieber eng an und erweitere gezielt, wenn ein Bedarf entsteht. Das ist deutlich einfacher, als hinterher zu klären, warum eine Rolle Rechte hat, die niemand mehr begründen kann.

• Arbeite im Alltag nicht mit Administratorrechten. Ein Administrator umgeht in Redmine alle Berechtigungsprüfungen - für ihn funktioniert immer alles, egal wie die Rollen gesetzt sind. Einen Fehler in den Rechten merkt er so nie. Der betroffene Anwender wiederum weiß gar nicht, was er können sollte, und meldet es deshalb auch nicht - oder er hält gleich das ganze System für schlecht, dabei stimmt nur die Konfiguration nicht. Gewöhn dir darum an, mit einem normalen Benutzerkonto zu arbeiten und Änderungen damit zu prüfen. Mit deinem Hintergrundwissen erkennst du am ehesten, wenn etwas nicht so läuft, wie du es gedacht hast.

• Weniger ist mehr - bilde nicht jede Unternehmensrolle 1:1 ab. Nur weil es im Organigramm Teamleitung, Fachbereich und drei Abteilungen gibt, braucht Redmine nicht für jede dieser Stellen eine eigene Rolle. Redmine-Rollen orientieren sich an Tätigkeiten im Projekt, nicht an Stellenbezeichnungen. Oft reichen ein paar gut zugeschnittene Rollen für das, wofür sonst ein Dutzend kaum unterscheidbarer Rollen angelegt wird. Je weniger Rollen du pflegen musst, desto leichter bleibt das Ganze nachvollziehbar.

• Benenne Rollen nach ihrer Funktion - und halte das auch ein. Eine Rolle “Manager mit Löschfunktion” sollte auch tatsächlich löschen dürfen. Klingt selbstverständlich, ist es in der Praxis aber nicht: Wir sehen regelmäßig Rollennamen, die ein Recht versprechen, das gar nicht hinterlegt ist. Spätestens beim nächsten Audit kostet das Zeit und Nerven.

• Prüfe nach jedem Plugin-Update kurz die Rechte. Updates können neue Berechtigungen mitbringen oder bestehende anders einsortieren. Ein kurzer Blick auf die betroffenen Rollen erspart dir die Rückfrage “warum ist das jetzt anders?”.

• Dokumentiere dein Rollenkonzept einmal sauber. Eine knappe Übersicht, welche Rolle wofür gedacht ist, reicht schon. Sie hilft jedem, der später dazukommt - und dir selbst, wenn du in einem Jahr nicht mehr weißt, warum du was entschieden hast.

Don’ts

• Häufe nicht alles auf eine Sammelrolle. Eine einzige “Mitarbeiter”-Rolle, die alles darf, ist bequem, aber nicht steuerbar. Sobald jemand etwas weniger dürfen soll, musst du eine zweite Rolle bauen und stehst wieder am Anfang.

• Schließe nicht von der Position auf die Rechte. Ein Geschäftsführer braucht in Redmine nicht automatisch Administratorrechte oder darf alles, nur weil er an der Spitze steht. Frag nicht “welche Position hat die Person?”, sondern “was muss die Person in Redmine tun, um ihre Aufgabe zu erfüllen?”. Rechte sollen die Funktion im Unternehmen unterstützen, nicht den Rang abbilden.

Wichtig: Der Administrator-Status ist in Redmine keine Rolle, sondern ein eigener Schalter im Benutzerprofil. Er übergeht das ganze Rollen- und Rechtesystem und sollte nur an Leute gehen, die Redmine wirklich administrieren - nicht an die mit dem höchsten Rang.

• Vermeide zwei fast gleich benannte Rollen mit unterschiedlichen Rechten. Oft gibt es einen guten Grund für zwei ähnliche Rollen - zum Beispiel interne und externe Entwickler, die unterschiedlich viel dürfen sollen. Nur heißen sie dann gern “Entwicklung” und “Mitarbeiter Entwicklung”, und nach ein paar Monaten weiß niemand mehr, welche welche ist. Wenn der Unterschied wichtig ist, mach ihn im Namen eindeutig - etwa “Entwicklung intern” und “Entwicklung extern”. So steht der eigentliche Grund direkt im Rollennamen.

• Ändere nicht im Live-Betrieb wild an Rechten herum. Teste Änderungen an einem unkritischen Testprojekt oder zumindest mit einer Testrolle, bevor du sie systemweit ausrollst.

So könnte ein einfaches Rollenkonzept aussehen

Damit ein Team sieht, welche Rolle was darf arbeitet man ein Rollenkonzept aus und veröffentlicht das am Besten in einer für alle zugänglichen Redmine Wiki-Seite. Im Idealfall sind die Rollen nach Funktion benannt und die Berechtigungen werden pro Rolle erweitert.

Tickets löschen: Redmine ist unter anderem auch ein Nachschlagewerk dafür, was wann wie in einem Projekt mal passiert ist - gelöschte Tickets reißen Lücken in diese Historie. Löschen gehört deshalb immer in Manager- oder sogar Admin-Hand.

Plugins bringen eigene Rechte mit

Wer kommerzielle Plugins einsetzt, sollte wissen, dass diese in der Regel ihre eigenen Berechtigungssektionen mitbringen. Beim Templates-Plugin etwa gibt es eine eigene Sektion, die zusätzlich zu den Standardrechten gesteuert wird. Das ServiceDesk-Plugin verhält sich ähnlich. Nach der Installation oder einem Update lohnt sich deshalb der Blick nicht nur auf die Standardrechte, sondern auch auf die plugin-spezifischen Abschnitte unter Administration -> Rollen und Rechte.

Schneller zum Konzept mit dem Redmine AI Plugin

Wer mit unserem Redmine AI Plugin bereits arbeitet, kann sich ein solches Konzept übrigens vom KI-Assistenten entwerfen lassen. Du beschreibst ihm direkt in Redmine deine Teams und ihre Aufgaben, und er liefert einen Vorschlag. Eingerichtet wird weiterhin von Hand, der Entwurf erleichtert dir jedoch den Start.

So kann zum Beispiel der Prompt aussehen:

Hilf mir, ein Rollen- und Rechtekonzept für unser Redmine zu entwerfen (deutsche Oberfläche). Arbeite nach dem Least-Privilege-Prinzip. Unsere Gruppen: interne Entwickler (arbeiten aktiv an Tickets, buchen Zeit), externe Entwickler (zeitweise im selben Projekt, sollen nur eigene Tickets sehen, keine fremden Zeitbuchungen, kein Löschen), Projektleitung. Schlage gestaffelte Rollen nach Funktion vor, liste je Rolle die konkreten Redmine-Berechtigungen auf, vergib Löschrechte nur an Manager/Admin und gib das Ergebnis als Berechtigungsmatrix aus.

Den Vorschlag übernimmst du nicht blind: Gleich ihn mit den Do’s und Don’ts aus diesem Beitrag ab und teste ihn mit einem normalen Benutzerkonto. Das AI Plugin ist als monatliches Add-on zu unserem Managed Redmine Hosting verfügbar.

Fazit

Das Rechtesystem von Redmine ist mächtig, aber kein Hexenwerk - vorausgesetzt, man behandelt es bewusst statt es einfach laufen zu lassen. Wer einmal ein klares, dokumentiertes Rollenkonzept aufsetzt und es nach Updates kurz gegencheckt, erspart sich genau das Rätselraten, mit dem dieser Beitrag begonnen hat.

Weiterführende Links

• Redmine Demo - Rollen und Rechte live ausprobieren
• AlphaNodes Redmine Produkte - Plugins mit eigenen Berechtigungen
• Redmine ServiceDesk - mit eigener Rechtesektion
• Managed Redmine Hosting von AlphaNodes

In Kundengesprächen sehen wir drei Konstellationen immer wieder. Vielleicht erkennst Du Dich in einer davon.

Konstellation 1: Compliance ist Pflicht

Im Gesundheitswesen, im Finanzsektor, in der öffentlichen Verwaltung oder Rechtsberatung sind Datenschutzbeauftragte mit GitLab.com selten zufrieden. Hauptthema ist die Verarbeitung in der US-Cloud: Drittlandtransfers, aufwändige Dokumentation, Risiko bei Datenschutzverstößen.

GitLab Hosting in deutschen Rechenzentren - als Cloud-Hosting bei uns oder Managed On-Premise auf Deiner Infrastruktur - nimmt Dir diese Diskussion ab. Source-Code, CI/CD-Artefakte und User-Daten bleiben in Deutschland.

Was das im Alltag bedeutet:

• DSGVO-konforme Verarbeitung ohne Folgenabschätzung für US-Transfers
• Auftragsverarbeitungsvertrag mit deutschem Ansprechpartner
• Auditfähige Dokumentation der Datenverarbeitung
• Branchenspezifische Anforderungen wie § 203 StGB, BaFin/MaRisk oder BSI-Grundschutz lassen sich sauber abbilden

Konstellation 2: Das Team wächst, das Budget nicht im selben Tempo

Bei GitLab.com zahlst Du pro User. Bei 50 Entwicklern ist das kalkulierbar, bei 200 wird das Gespräch mit dem Controlling anders. Eine Migration weg von GitLab.com ist später zwar möglich, aber aufwändig.

Unser Hosting läuft mit einer monatlichen Pauschale, unabhängig von der User-Zahl. Ob Dein Team auf 50 oder 500 Personen wächst, das Hosting kostet das Gleiche. Updates, Backups, Monitoring und Support sind enthalten.

Falls Du GitLab Enterprise-Features wie Security-Scanning oder Compliance-Dashboards brauchst, buchst Du die EE-Lizenzen direkt bei GitLab. Unser Hosting-Paket bleibt davon unberührt. So zahlst Du gezielt für die Features, die Du wirklich nutzt.

Konstellation 3: GitLab ja, aber niemand will Admin sein

Diese Konstellation sehen wir oft: GitLab wird im Team intensiv genutzt, aber niemand hat Zeit oder Lust, sich um Updates, Security Patches und Backups zu kümmern. GitLab.com fällt aus Datenschutzgründen raus, Self-Hosting bindet Ressourcen, die für die eigentliche Entwicklung fehlen.

Bei Managed Application Hosting übernehmen wir die Infrastruktur-Seite, Dein Team kümmert sich um die Software. Das umfasst Setup, regelmäßige Updates für GitLab und das darunterliegende System, tägliche Backups mit definierten Restore-Zeiten, Monitoring sowie E-Mail-Support während unserer Geschäftszeiten.

Klingt unspektakulär - ist im Alltag aber genau das, was Entwicklungsteams entlastet.

GitLab + Redmine Integration

Nutzt Du bereits Redmine für Projektmanagement? GitLab lässt sich nahtlos integrieren - ideal für Teams, die Projektplanung und Code-Entwicklung verknüpfen möchten.

Mehr zur Redmine-Integration

Bonus: Redmine-Integration für Projektmanagement

Falls Du bereits Redmine für Projektmanagement nutzt: GitLab und Redmine lassen sich gut verbinden. Ticket-Referenzen in Commits, automatische Updates bei Merge Requests - so verzahnen sich Projektmanagement in Redmine und Code-Entwicklung in GitLab.

GitLab bringt eine eigene Issue-Funktion mit, die für viele entwicklungszentrierte Teams ausreicht. Die Redmine-Integration ist dann sinnvoll, wenn Du:

• Projektmanagement über reine Dev-Tasks hinaus brauchst (Budget-Tracking, Meilensteine, Gantt-Charts)
• externe Stakeholder einbinden willst (Kunden, Management, nicht-technische Projektbeteiligte)
• Ressourcenplanung und HRM-Features benötigst (Urlaubsverwaltung, Zeiterfassung, Kapazitätsplanung)
• komplexe Workflows abbilden musst, die über GitLab Boards hinausgehen
• bereits Redmine nutzt und die bestehende Projektstruktur mit GitLab verknüpfen willst

Für reine Entwicklungsteams ohne diese Anforderungen ist GitLab Issues oft die einfachere Wahl. Für organisationsweites Projektmanagement mit DevOps-Integration spielt die Kombination GitLab + Redmine ihre Stärken aus. Wir hosten beide Systeme - egal ob Du Dich für GitLab standalone oder die Integration mit Redmine entscheidest.

Deine nächsten Schritte

Welche Variante zu Dir passt, hängt von Deinen Anforderungen ab. Wir bieten zwei Modelle an:

• Cloud-Hosting: GitLab auf unserer Infrastruktur in deutschen Rechenzentren
• Managed On-Premise: GitLab auf Deiner Infrastruktur (eigener Server oder Cloud-Provider)

Mindestlaufzeit ein Monat, kündbar mit zwei Wochen Frist. Setup, Updates, Monitoring, Backups und technischer Ansprechpartner sind enthalten.

Fragen zu GitLab Managed Hosting? Schau in unsere FAQ oder schreib uns direkt für ein individuelles Angebot.

Weiterführende Infos

• GitLab Managed Application Hosting FAQ
• Unsere GitLab Hosting Angebote

Kurzinfo zum Redmine AI Plugin: Nutze KI-Funktionen direkt in Redmine - automatische Ticket-Zusammenfassungen, KI-gestützte Antwortvorschläge, semantische Suche und intelligente Automatisierung. Spare Zeit bei Routineaufgaben und konzentriere Dich auf komplexe Probleme.

Für wen ist dieser Beitrag relevant?

• Datenschutzverantwortliche, die KI-Setups in Redmine einschätzen müssen
• Bestandskunden unseres Managed Hostings, die wissen wollen, wie wir uns auf den Stichtag vorbereiten
• Interessenten und Redmine-Anwender vor einer Plugin-Entscheidung, die die Verantwortungsteilung zwischen Plugin-Anbieter und Betreiber einschätzen wollen

Wenn Du KI in Redmine derzeit nicht einsetzt und auch nicht plant, dann besteht für Dich aktuell keine akute Handlungspflicht.

Konkret sind drei Stellen betroffen:

• Vertragliche Grundlage geschaffen: Die Verantwortungsteilung zwischen AlphaNodes als Plugin-Anbieter und Dir als Betreiber ist in unserer Hosting-AGB festgehalten.
• Technische Umsetzung im Plugin: Die maschinenlesbare Markierung von KI-generierten Inhalten ist Teil der Plugin-Entwicklung und wird zum Stichtag bereitstehen.
• Provider-Auswahl mit Datenschutzfokus: Unser AI Plugin ermöglicht die Anbindung an verschiedene KI-Provider. Du kannst also zwischen mehreren KI-Providern wählen. Unter anderem auch ein lokal betriebenes Ollama (z. B. über unser Managed AI Hosting in Deutschland) oder Azure OpenAI in EU-Region.

Geteilte Verantwortung

Die EU-KI-Verordnung weist Anbietern und Betreibern unterschiedliche Pflichten zu. In unserem Setup heißt das konkret:

Was AlphaNodes auf Anbieter-Seite übernimmt:

• Maschinenlesbare Markierung des KI-Outputs im Plugin
• Hinweis auf KI-Interaktion in Chat- und Assistent-Funktionen
• Wartung und Updates der Plugin-Komponente

Was beim Kunden liegt (Betreiber-Seite):

• Bewertung des eigenen KI-Einsatzes durch den unternehmensinternen Datenschutzverantwortlichen
• Sichtbare Kennzeichnung bestimmter veröffentlichter Inhalte, sofern im konkreten Fall relevant
• Dokumentation der internen KI-Kompetenz - eine Anforderung, die bereits seit Februar 2025 wirksam ist

Hinweis: Dieser Beitrag ersetzt keine rechtliche oder datenschutzrechtliche Beratung. Die abschließende Bewertung Deiner spezifischen Situation liegt immer beim Datenschutzverantwortlichen Deines Unternehmens und gegebenenfalls einem spezialisierten Rechtsbeistand (dazu gehören beispielsweise Risiko-Einstufung, Vertragsfragen und branchenspezifischer Vorgaben etc.).

Weiterführende Links

• Redmine AI Plugin von AlphaNodes
• DSGVO-konformes Redmine AI Hosting mit Managed Ollama
• Hosting-AGB

Reine Timer-Tools sind für genau dieses Buchungsmuster nicht ideal: starten, vergessen, korrigieren, oder nochmal von vorne. Das klassische Buchungs-Formular von Redmine ist ebenfalls nicht geeignet (ein einzelner Eintrag pro Tag, pro Ticket).

Mit dem Redmine Timesheet Plugin stellen wir ein Plugin bereit, das diese beiden Muster gleichwertig unterstützt: einen wöchentlichen Stundenzettel als Raster und einen Timer für die Echtzeit-Erfassung.

Zwei Wege zum Ziel

Es hat sich in der Praxis gezeigt, dass es zwei Sorten von Zeiterfassern in einem Team gibt:

• Der Echtzeit-Tracker. Beginnt mit dem Ticket, klickt auf Start, arbeitet, klickt auf Stopp. Der Timer ist im Account-Menü auf jeder Redmine-Seite sichtbar, lässt sich pausieren, wieder starten und meldet beim Ticketwechsel automatisch um. Pro Benutzer läuft bewusst maximal ein Timer, um inkonsistente Mehrfachbuchungen zu vermeiden.

• Der Freitag-Nachtrager. Öffnet am Wochenende oder direkt vor der Stundenabrechnung den Stundenzettel und sieht ein Wochenraster: links die Tickets, oben die Wochentage, in den Zellen die Stunden. Tickets werden per Autovervollständigung hinzugefügt, Stunden eingetragen, abgespeichert. Fertig. Bereits gebuchte Einträge werden aktualisiert, leere gelöscht.

Mehr als nur Eintragen

Drei Funktionen, die im Arbeitsalltag den Unterschied machen:

• Verlinkte Summen. Jede Tages-, Zeilen- und Wochensumme im Raster ist ein Link auf die gefilterte Standard-Ansicht Aufgewendete Zeit. Vom Überblick ins Detail mit nur zwei Klicks.
• Vorwoche kopieren. Eine Schaltfläche genügt, um Tickets, Tätigkeiten, Stunden und Kommentare aus der Vorwoche ins aktuelle Raster zu übernehmen. Das spart Zeit.
• Team-Übersicht “Alle Benutzer”. Ideal für Teamleiter ist die schreibgeschützte Wochenmatrix mit allen Buchungen pro Benutzer und Tag.

Wer zusätzlich unser Redmine HRM Plugin einsetzt, sieht im Stundenzettel automatisch die Tages- und Wochen-Sollzeiten aus dem zugewiesenen Arbeitskalender, einen Fortschrittsbalken pro Tag und einen Über-Stunden-Indikator, sobald das Tagesziel überschritten wird.

Was Du davon hast

Eine einzelne Buchung dauert nicht länger als bisher - aber pro Woche und Mitarbeiter spart das Plugin spürbar Zeit, weil der Wechsel zwischen Tickets und Tagen entfällt, Wiederholungen wegfallen und die wöchentliche Kontrolle direkt aus dem Raster heraus läuft. Wichtig: Wer am Freitag eine ganze Woche nachtragen will, hat jetzt das besser passende Werkzeug dafür.

Fazit

Die Zeiterfassung in Redmine wird nicht dadurch besser, weil die Möglichkeit besteht, dass eine Stoppuhr läuft, sondern, weil der Anwender durch das Wochenraster eine übersichtliche Ansicht erhält, die wahrscheinlich besser zum tatsächlichen Buchungsverhalten passt.

Das Redmine Timesheet Plugin liefert zwei Wege Aufwandsbuchungen zu Tickets zu hinterlegen: Echtzeit-Tracking für die einen, Wochengrid mit Komfortfunktionen für die anderen.

Weiterführende Links

• Managed Redmine Hosting bei AlphaNodes
• Redmine HRM Plugin

Häufige Fragen (FAQ)

Warum ist das für Dich als Redmine-Verantwortlichen wichtig?

Es liegt am Admin oder der Teamleitung, die entscheidet, wie KI im Team ankommt. Ein “hier hast Du Zugang zur KI” führt erfahrungsgemäß zu zwei Problemen: Die Ergebnisqualität schwankt je nach Anwender stark, und Mitarbeiter ohne Prompt-Erfahrung nutzen das Feature einfach nicht. Vordefinierte Prompts lösen beide Punkte. Sie machen KI standardisiert und unterschwellig für das gesamte Team nutzbar.

Was sind vordefinierte KI-Prompts in Redmine?

Vordefinierte Prompts sind wiederverwendbare Arbeitsaufträge an die KI, die Anwender mit entsprechender Berechtigung (z.B. Du als Admin) einmal sauber formulieren und Deinem Team zur Verfügung stellen. Sie erscheinen als Schaltfläche direkt dort, wo Dein Team ohnehin arbeitet - in der Ticketansicht, aber auch in Wiki-Seiten. Ein Klick genügt, und das Ergebnis erscheint direkt an verschiedenen Stellen des Tickets. Der Anwender selbst muss keinen Prompt schreiben, nichts formatieren, nichts kopieren.

Die Ticketansicht ist dabei der wichtigste Einsatzort, weil die meisten Rollen im Projekt dort den größten Teil ihrer Arbeitszeit verbringen. Vom Sekretariat über Teamleitung bis zu Entwicklern. Typische Einsätze in der Ticketansicht sind etwa:

• Inhalt eines langen Tickets in drei Sätzen zusammenfassen
• Priorität und Komplexität automatisch einschätzen lassen
• Ähnliche Tickets aus dem Projektarchiv finden (per RAG)
• Den Status eines Tickets in kundenfreundlicher Sprache ausgeben

Ein Beispiel aus dem Arbeitsalltag

Wie das konkret aussieht, zeigt ein typisches Ticket, das von verschiedenen Rollen im Team angesehen wird. Ticket #2847: “Datenbank-Performance bei Monatsabschluss eingebrochen” - inzwischen 15 Kommentare, technische Analyse, mehrere Zwischenstände.

1. Die Sekretärin antwortet auf eine Kundenanfrage

Der Kunde ruft an und möchte wissen, wo das Problem steht. Die Sekretärin hat keinen technischen Hintergrund - und müsste normalerweise 15 Kommentare lesen oder einen Kollegen stören. Stattdessen öffnet sie das Ticket und klickt auf den vordefinierten Prompt “Ticketstatus in Kundensprache zusammenfassen”. Direkt unterhalb erscheint eine freundliche, laienverständliche Zusammenfassung. Die kann sie dem Kunden am Telefon vorlesen oder per E-Mail senden.

2. Der Geschäftsführer prüft den Projektstand

Er will wissen, wie viel Aufwand noch vor dem Team liegt, hat aber keine Zeit, sich durch technische Details zu arbeiten. Er öffnet dasselbe Ticket und klickt auf “Aufwand und Fortschritt einschätzen”. Die KI analysiert den gesamten Verlauf und liefert: aktueller Status, erkennbare nächste Schritte, realistische Einschätzung der Restzeit. Entscheidung möglich in unter einer Minute - und ohne den Teamleiter stören zu müssen.

3. Der Entwickler sucht nach einer vergleichbaren Lösung

Er bearbeitet das Ticket und sieht direkt in der Ticketansicht einen Vorschlag “Ähnliche Tickets”. Das Plugin nutzt RAG-Technologie, durchsucht alle Projekttickets und findet einen vergleichbaren Performance-Einbruch aus dem letzten Jahr - inklusive der damaligen Lösung. Das erspart ihm die Recherche und liefert direkt einen Ansatzpunkt für die Analyse. Wie “Ähnliche Tickets” sind auch relevante Wiki-Seiten integriert.

Der entscheidende Punkt

Diese Prompts hat der Admin einmal definiert. Sie stehen allen passenden Rollen dauerhaft zur Verfügung - konsistent, und ohne dass jemand im Team “gute Prompts schreiben” lernen muss. Sie müssen nur bei Bedarf angepasst werden. Ob ein Ticket mit drei oder hundert Kommentaren, die KI liefert dieselbe Art von Zusammenfassung, Einschätzung oder Referenz. Prompt-Engineering wird einmal zentral eingerichtet, das Team nutzt es im Arbeitsalltag.

Das gleiche Prinzip funktioniert übrigens auch in der Wiki-Ansicht - etwa um lange Wiki-Artikel auf das Wesentliche einzudampfen oder die Vollständigkeit einer Dokumentation prüfen zu lassen.

Was Du davon hast

Eine einzelne KI-Anfrage spart nur wenige Minuten. Multipliziert sich das aber mit der Team-Größe und der Anzahl an Tickets, die täglich bearbeitet, kommentiert oder geprüft werden, summiert sich das spürbar. Dazu kommt: Du kannst KI schneller produktiv einsetzen, weil niemand mehr zwingend lernen muss, wie man Prompts formuliert. Der Prompt ist schon da, der Anwender muss ihn lediglich auswählen.

Fazit

KI im Redmine wird nicht dadurch produktiv, dass Du ein größeres oder teureres Modell einsetzt - sondern dadurch, dass Du Deinem Team die richtigen Werkzeuge in die Hand gibst. Vordefinierte Prompts sind genau dieses Werkzeug: Sie machen KI standardisiert, niederschwellig und reproduzierbar nutzbar.

Mit dem AlphaNodes Redmine AI Add-On richtest Du die Prompts einmal zentral ein - und das ganze Team profitiert. Ob Du dafür einen externen Anbieter wie OpenAI oder Claude nutzt oder ein eigenes DSGVO-konformes Ollama-Setup im Hintergrund, bleibt Deiner Entscheidung überlassen.

Weiterführende Links

• AlphaNodes Redmine AI Hosting - KI für Dein Projektmanagement
• Managed Redmine Hosting bei AlphaNodes
• Redmine AI Entscheidungshilfe

Häufige Fragen (FAQ)

Das Redmine Automation Plugin löst genau solche Probleme, indem es dein Projektmanagement von reaktiv zu proaktiv macht. Statt dem Team hinterherzulaufen, arbeitet das System für dich mit.

Automatisierungen im Redmine Automation Plugin basieren auf einer Regel (bestehend aus Trigger + Bedingung + Aktion) und diese funktioniert nach dem “Wenn-Dann”-Prinzip. Das Plugin überwacht kontinuierlich alle definierten Trigger und führt die entsprechenden Aktionen aus, sobald die Bedingungen erfüllt sind - ohne dass ein Benutzer eingreifen muss.

Nie wieder überfällige Tickets übersehen

Stell dir vor, jedes überfällige Ticket wird automatisch an deinen Projektleiter weitergeleitet und gleichzeitig auf “Hoch” priorisiert. Das passiert ganz von selbst, ohne dass du daran denken musst. So entstehen erst gar keine Engpässe.

Automatisierungsbeispiel: Überfällige Tickets → Eskalation an Projektleiter + Priorität erhöhen

Proaktive Sprint-Planung

Jeden Freitag erstellt das System automatisch ein “Sprint Planning Meeting”-Ticket für den Scrum Master. So vergesst ihr nie wieder die Vorbereitung für den nächsten Sprint. Über die Funktion “Ticket-Wiederholung” legst du das gewünschte Intervall dafür einfach selbst fest.

Automatisierungsbeispiel: Sprint Planning → wöchentliches Ticket für den Scrum Master

Intelligente Ticket-Zuweisung

Warum solltest du jeden Bug manuell dem Entwicklerteam zuweisen? Das Plugin kann das automatisch basierend auf dem Ticket-Typ machen. Bug-Reports landen direkt beim Entwicklerteam, Feature-Requests beim Product Owner.

Automatische Qualitätssicherung

Sobald ein Feature beispielsweise als “Ready for Review” markiert wird (mittels benutzerdefiniertem Feld für Tickets, mittels Tag oder mittels Kategorie), bekommt automatisch ein Senior Developer das Ticket zugewiesen - mit einem Fälligkeitsdatum in zwei Tagen. Code-Reviews werden so zu einem festen, nachverfolgbaren Prozess.

Budget im Blick behalten

Das Plugin überwacht täglich eure Zeitbuchungen und warnt automatisch, wenn jemand mehr als 8 Stunden pro Tag erfasst hat. Überstunden bleiben so nicht unentdeckt.

Stakeholder immer informiert

Kritische Tickets oder Meilenstein-Updates werden automatisch an die relevanten Stakeholder gesendet. Transparenz ohne zusätzlichen Aufwand für dein Team.

Projektabschluss strukturieren

Wird ein Projekt geschlossen, versendet das System automatisch eine “Projekt-Retrospektive”-Meeting Einladung und informiert alle Beteiligten. Lessons Learned gehen so nicht verloren.

Automatisierungsbeispiel: Projekt geschlossen → Mailversand an Projektteam

Der Blick aufs große Ganze

Diese Automatisierungen mögen einzeln betrachtet klein erscheinen. In der Summe verwandeln sie jedoch auch chaotische Projektmanagement-Teams in eine gut eingespielte Truppe. Statt reaktiv Probleme zu lösen, verhinderst du sie proaktiv.

Das Beste daran: Einmal durchdacht eingerichtet, läuft alles weitere von selbst. Es reicht ab und zu den Nutzen zu überprüfen und Logdateien zu sichten. Dein Team kann sich auf die wirklich wichtigen Aufgaben konzentrieren, während die Routine im Hintergrund automatisch abgearbeitet wird.

ROI (Return on Investment) selbst bei kleinen Automatisierungen gegeben

Selbst in kleinen Teams oder mit wenig Automatisierungen lässt sich mit dem Plugin längerfristig Zeit sparen.

Wer an jedem Arbeitstag 10 Minuten braucht, um alle Tickets zu sichten und Statusangaben oder Zuweisungen zu ändern oder Mails zu verschicken, spart pro Woche bereits 50 Minuten:

Das sind im Monat bei einer Person: 3 Stunden 20 Minuten gespart.

Aber der wahre Wert liegt nicht nur in der Zeitersparnis. Weniger vergessene Deadlines bedeuten zufriedenere Kunden. Automatische Eskalationen verhindern, dass kleine Probleme zu großen werden. Strukturierte Code-Reviews reduzieren Bugs in der Produktion.

Diese “weichen Faktoren” sind schwer zu quantifizieren, können aber den ROI nochmals verdoppeln oder verdreifachen.

Eine Übersicht aller zur Auswahl stehenden Trigger und Aktionen für die Automatisierungsregeln findest du in unserem Cheat-Sheet zu Regel-Aktionen.

Für wen das Automation Plugin interessant ist

Das Plugin ist in erster Linie für agile Software-Teams, Projektmanager und Redmine-Administratoren gedacht, die wiederkehrende Abläufe im Griff behalten wollen. Durch die automatische Protokollierung aller Aktionen eignet es sich zudem für Umgebungen mit erhöhten Anforderungen an Nachvollziehbarkeit und Audit-Fähigkeit.

Noch einen Schritt weiter: KI-gestützte Automatisierung

Klassische Wenn-Dann-Regeln kommen dort an ihre Grenzen, wo Entscheidungen vom Inhalt eines Tickets abhängen. Genau hier setzt das Redmine AI Plugin auf: In Kombination mit dem Automation Plugin stehen zusätzliche KI-Aktionen zur Verfügung, mit denen Tickets inhaltlich klassifiziert, priorisiert und zugewiesen werden - basierend auf dem tatsächlichen Text, nicht nur auf Stichworten.

Wie das konkret aussieht, zeigt der Blogbeitrag KI-gestützte Automatisierung in Redmine.

Fazit

Das Redmine Automation Plugin ist ein unermüdlicher Assistent, der seine Aufgaben wie von dir definiert abarbeitet. Von der Ticket-Zuweisung über Budget-Überwachung bis hin zur Stakeholder-Kommunikation - all diese Routineaufgaben laufen mit dem Plugin zukünftig automatisch ab.

Das Redmine Automation Plugin der AlphaNodes GmbH aus Deutschland (Bayern) steigert sowohl die Effizienz als auch Zuverlässigkeit von Projektabläufen, indem wiederkehrende Aufgaben automatisch ausgeführt werden. Damit unterstützt das Plugin nicht nur die Optimierung interner Abläufe, sondern leistet auch einen Beitrag zu höherer Kundenzufriedenheit und besserer Planbarkeit.

Alle Informationen zu unseren Erweiterungen für Redmine gibt es auf der Produktseite. Kunden, deren Redmine den Mindestanforderungen nicht entspricht oder die lieber jemanden für die Installation und regelmäßige Pflege ihrer Redmine-Instanz beauftragen wollen, haben alternativ die Möglichkeit unser Managed Applikation Hosting für Redmine zu buchen. Hier ist das Plugin auf Wunsch Teil unseres Hosting Angebots. Das Automation Plugin ist außerdem Teil unseres Enterprise+ Bundle, einer abgestimmten Auswahl unserer Plugins.

Weiterführende Infos

• Redmine Automation Plugin
• Feature Liste
• Kurz vorgestellt: Filter für Variablen
• Redmine Online-Demo