Redmine Dashboards
DashboardsDashboards aus den gespeicherten Abfragen, die Sie ohnehin schon haben — ein Raster aus KPI-Kacheln, Tabellen und fünfzehn Diagrammtypen per Drag-and-drop, in SQL aggregiert und auf das beschränkt, was die betrachtende Person sehen darf.
Mehrere Server: $399
- Widget-Typen
- 23
- Diagrammvarianten
- 15
- Redmine
- 4 · 5 · 6 · 7
- Datenbanken
- MySQL, MariaDB, PostgreSQL
- Core-Patches
- Keine
Bauen per Drag-and-drop
Ein Raster, dessen Kacheln sich frei verschieben und in der Größe ändern lassen und das sich beim Arbeiten selbst speichert. Ordnen Sie KPIs, Diagramme und Tabellen an, bis das Board die Geschichte erzählt, die Sie brauchen — ohne Layout-Datei, ohne Neuladen.
Fünfzehn Diagrammtypen
Balken, liegende Balken, gestapelte Balken, Linie, Mehrfachlinie, Fläche, Kreis, Ring, Radar, Polar, Tacho, Trichter, Heatmap, Treemap und Fortschrittsring — gezeichnet mit Apache ECharts, hell wie dunkel.
Ihre gespeicherten Abfragen, visualisiert
Richten Sie ein Widget auf eine gespeicherte Abfrage, und es übernimmt deren Filter — samt benutzerdefinierten Feldern, Beobachtern und Unterprojekten. Oder machen Sie aus der Abfrage mit einem Klick ein ganzes Board.
In SQL aggregiert
GROUP BY, COUNT, SUM und AVG laufen in der Datenbank, sodass hunderttausend Tickets gezählt und nicht instanziiert werden. Ergebnisse werden je Benutzer, Widget und aktiven Filtern zwischengespeichert.
Auf den Betrachter zugeschnitten
Jeder Lesezugriff beginnt bei Issue.visible(user), TimeEntry.visible(user) und Query.visible(user) — kein Diagramm kann also eine Summe aus einem Projekt zeigen, in dem die lesende Person kein Mitglied ist.
Filter, Aktualisierung und Absprung
Eine Filterleiste stellt das gesamte Board neu ein, ein Intervall je Dashboard hält eine Wandanzeige aktuell, und jeder Balken, jedes Segment und jede Zelle führt in die dahinterliegende Ticketliste.
So sieht es in Redmine aus
Jeder Screenshot hier stammt aus einer unveränderten Redmine-6-Installation, in deren plugins/ das Plugin einfach abgelegt wurde. Die Dashboards sitzen unter Redmines eigener Kopfzeile und seinen Menüs, denn genau dort laufen sie.
Ein Board bauen
Widgets
Teilen und wechseln
Die Abfrage ist bereits der Bericht
Nichts hier verlangt, dass Sie Ihre Daten ein zweites Mal beschreiben. Filtern Sie eine Ticketliste wie immer, speichern Sie sie, und diese gespeicherte Abfrage wird zu dem Bereich, über den ein Widget aggregiert — dieselbe Relation, mit der Redmine die Liste selbst darstellt.
| Schritt | Was Sie tun | Was Sie bekommen |
|---|---|---|
| 1. Abfrage speichern | Die Ticketliste filtern — benutzerdefinierte Felder, Beobachter, Unterprojekte — und auf Speichern klicken | Eine benannte Abfrage, sichtbar für die, mit denen Sie sie geteilt haben |
| 2. Ein Widget darauf richten | Diese Abfrage im Widget-Dialog auswählen | Datenquelle und eine sinnvolle Standardgruppierung, für Sie abgeleitet |
| 3. Oder gleich das ganze Board | Auf „Aus Abfrage“ klicken | Ein Dashboard aus KPI-Kacheln und Diagrammen, an sie gebunden, in einer einzigen Anfrage |
Aus Auswahlfeldern konfiguriert, nicht aus SQL
Ein Widget besteht aus Quelle, Dimension, Kennzahl und Aggregation. Gruppieren Sie Tickets nach Status, Priorität, Tracker, Bearbeiter oder einem beliebigen Datumsfeld in Tages-, Wochen-, Monats- oder Jahresbuckets; zählen Sie sie, summieren Sie geschätzte Stunden oder mitteln Sie den Fortschritt. Niemand im Team schreibt SQL für ein Diagramm — und weil es kein SQL zu schreiben gibt, gibt es auch keine Abfrage, die über die Berechtigungen der lesenden Person hinausgreifen könnte.
Jedes Widget aus einem Formular konfiguriert
Jedes Widget, ob KPI, Balken oder Ring, wird im selben kurzen Formular eingerichtet: Titel und Typ, eine Datenquelle, optional eine gespeicherte Abfrage für die Filter, eine Kennzahl und eine Gruppierung mit Top-N. Wechseln Sie den Typ, und das Formular passt sich an.
Eine Einstellungsseite für Administratoren
Unter Administration › Plugins › Redmine Charts legen Sie das Ergebnis-Caching je Benutzer fest, die Cache-TTL (5–86400 Sekunden, Standard 300), das Standardthema hell oder dunkel sowie ein Standardintervall für die automatische Aktualisierung, wobei 0 sie abschaltet. Die Seite ist Redmines eigene Einstellungsseite für Plugins.
23 Widget-Typen, und Platz für Ihre
Jeder Typ ist Metadaten aus einer Registry, sodass sich die Konfigurationsoberfläche aus der Deklaration des Widgets selbst aufbaut statt aus einem handgeschriebenen Formular je Diagramm.
| Familie | Typen | Konfiguriert mit |
|---|---|---|
| Diagramme | Balken, liegende Balken, gestapelte Balken, Linie, Mehrfachlinie, Fläche, Kreis, Ring, Radar, Polar, Tacho, Trichter, Heatmap, Treemap, Fortschrittsring | Quelle, Dimension, Kennzahl, Aggregation |
| KPI / Zahl | Eine einzelne aggregierte Kennzahl mit eigenem Filter | count · sum · avg · min · max |
| Tabelle | Ein seitenweises Raster über dieselben berechtigungsgeprüften Daten | Spaltenauswahl und Filter |
| Inhalt | Markdown, Notizen, HTML, iframe, Aktivitäten-Feed, letzte Tickets | Freier Text oder einer von Redmines eigenen Feeds |
Gezeichnet mit Apache ECharts
Fünfzehn Varianten, für hell und dunkel gestaltet, beim Skalieren neu gezeichnet und auch auf einer Wandanzeige noch lesbar. Das Bundle liegt fertig gebaut im Paket, die Installation braucht also weder Node noch einen Build-Schritt.
Jedes Segment führt in die Tiefe
Ein Klick auf einen Balken, ein Kreissegment oder eine Heatmap-Zelle öffnet die Redmine-Ticketliste, gefiltert auf genau diese Tickets. Die Zahlen bleiben prüfbar, weil Sie immer bei den Zeilen dahinter landen können.
Globale Filter und automatische Aktualisierung
Eine Filterleiste stellt alle Widgets eines Boards auf einmal neu ein, und ein Aktualisierungsintervall je Dashboard hält den Bildschirm im Flur aktuell. Null schaltet die Aktualisierung ab.
Vorlagen und Blaupausen
Speichern Sie ein Board als wiederverwendbare Vorlage, duplizieren Sie es je Team, oder exportieren Sie es als JSON-Blaupause und importieren es in eine andere Instanz — von Staging nach Produktiv, ohne es neu zu bauen.
Ein Plugin, ein Board für jedes Team
Eine Delivery-Leitung, ein Support-Desk und ein einzelner Entwickler haben diese Boards jeweils in wenigen Minuten gebaut — aus gespeicherten Abfragen, die sie schon hatten.
Zwei Quellen eingebaut, Ihre daneben
Tickets und Zeiterfassung bringen ihre Dimensionen und Kennzahlen von Anfang an mit, beide hinter Redmines eigenen Sichtbarkeitsbereichen. Eine Quelle, die ein anderes Plugin registriert, wird genauso behandelt.
| Quelle | Dimensionen | Kennzahlen |
|---|---|---|
| Tickets | Status, Priorität, Tracker, Projekt, Bearbeiter, Autor, Kategorie, Version, erstellt, aktualisiert, Fälligkeitsdatum | Ticketanzahl, geschätzte Stunden, Fortschritt |
| Zeiterfassung | Projekt, Benutzer, Tätigkeit, Datum | Stunden, Anzahl Einträge |
| Ihre eigene | Was immer Sie registrieren | Was immer Sie registrieren |
Erweitern heißt registrieren, nicht patchen
Eine Datenquelle ist eine Klasse mit einem Namen, ihren Dimensionen, ihren Kennzahlen und einem berechtigungsgeprüften base_scope; ein Widget-Typ ist ein Hash. Registrieren Sie beides aus der init.rb Ihres eigenen Plugins mit RedmineCharts.register_data_source oder register_widget_type, und es erscheint sofort in der Konfigurationsoberfläche — mitsamt Filterung, Caching und Absprung in die Ticketliste. Dafür wird an diesem Plugin nichts geändert.
Niemand aggregiert, was er nicht lesen darf
Ein Dashboard ist ein schneller Weg, eine Zahl preiszugeben. Deshalb beginnt jeder Lesezugriff beim Sichtbarkeitsbereich der betrachtenden Person, statt mit einer Prüfung dagegen zu enden.
Erst Sichtbarkeit, dann Gruppierung
Issue.visible(user), TimeEntry.visible(user) und Query.visible(user) schränken die Relation ein, bevor eine einzige Zeile gezählt wird. Eine Summe aus einem Projekt, in dem Sie kein Mitglied sind, kann in keinem Widget auftauchen, weil diese Zeilen nie in der Menge waren.
Vier feingranulare Berechtigungen
Dashboards ansehen, anlegen, alle verwalten, Vorlagen verwalten — jede einzeln je Rolle vergebbar. Und alles bleibt aus, bis jemand das Dashboards-Modul für das Projekt aktiviert.
Teilen über Mitgliedschaften
Geben Sie ein Board für Benutzer, Gruppen, Rollen oder ganze Projekte frei. Jede Anfrage löst viewable_by? und editable_by? erneut über Redmines eigene Mitgliedschaften auf, statt über eine parallele Zugriffsliste, die aus dem Tritt gerät.
Nichts verlässt den Server
Das Frontend spricht ausschließlich mit der JSON-API dieses Plugins auf Ihrem eigenen Redmine, über die Sitzung und das CSRF-Token, die ohnehin da sind. Kein externer Dienst, kein Lizenz-Callhome, keine Telemetrie.
Gebaut für große Instanzen
Hunderttausend Tickets zu zählen sollte nicht bedeuten, hunderttausend Objekte zu laden. Hier bedeutet es das nicht.
| Thema | Wie es gelöst ist |
|---|---|
| Aggregation | GROUP BY, COUNT, SUM und AVG laufen in SQL — Zeilen werden nie instanziiert, nur um gezählt zu werden |
| Breite Dimensionen | Top-N-Faltung hält die Antwort klein, wenn eine Dimension tausende Ausprägungen hat |
| Wiederholte Aufrufe | Ergebnisse werden je Benutzer, Widget-Änderungszeit und aktiven Filtern über Rails.cache zwischengespeichert; die TTL ist eine Einstellung, Redis funktioniert unverändert |
| Ein langsames Widget | Widgets laden unabhängig voneinander, eine schwere Abfrage hält also nie das ganze Board auf |
| Fehlendes JS-Bundle | Rails rendert die Daten jedes Widgets serverseitig als Rückfallebene, die Seite degradiert also, statt leer zu bleiben |
Bewusst portabel, nicht zufällig
Die Unterstützung über Versionen und Datenbanken hinweg ist eingeplant — Migrationen, JSON-Speicherung und Datumsgruppierung wurden alle so geschrieben, dass sie die Unterschiede überstehen.
| Thema | Unterstützt | Wie |
|---|---|---|
| Redmine | 4.x, 5.x, 6.x, 7.x | Deklariert requires_redmine version_or_higher 4.0.0, ohne Core-Overrides, die veralten könnten |
| Rails | 5.2 → 8.0 | Migrationen zielen auf die Basis 5.2, die jede Version bis 8.0 versteht |
| Ruby | 2.5+ | Entspricht der Mindestanforderung von Redmine 4 |
| Datenbanken | MySQL, MariaDB, PostgreSQL | JSON liegt in einfachen Textspalten — überall identisches DDL — mit einem Serializer, der je Rails-Version die passende Form wählt |
| Datumsgruppierung | Tag, Woche, Monat, Jahr | Gruppiert über ein portables CAST(col AS DATE) und fasst dann in Ruby zu Buckets zusammen — kein herstellerspezifisches SQL |
| Migrationen erneut ausführen | Gefahrlos | Defensiv geschrieben, sodass sich ein abgebrochenes Upgrade wiederholen lässt |
Vom ersten Tag an skriptbar
Jeder Endpunkt liegt unter /redmine_charts/api, liefert JSON und erzwingt genau die Berechtigungen der Oberfläche — Boards lassen sich also aus der CI bereitstellen oder je Team erzeugen.
| Methode | Pfad | Was er tut |
|---|---|---|
| GET | /dashboards | Jedes Dashboard, das der Aufrufer sehen darf |
| POST | /dashboards | Eines anlegen |
| GET | /dashboards/:id | Ein Dashboard samt seinen Widgets holen |
| PATCH | /dashboards/:id | Name, Layout oder Einstellungen ändern |
| POST | /dashboards/:id/duplicate | Es klonen, Widgets inklusive |
| GET | /dashboards/:id/export | Eine JSON-Blaupause exportieren |
| POST | /dashboards/import | Ein Board aus einer Blaupause anlegen |
| POST | /dashboards/:id/widgets | Ein Widget hinzufügen |
| GET | /widgets/:id/data | Aggregierte, berechtigungsgeprüfte Widget-Daten |
| GET | /meta/data_sources | Quellen, Dimensionen, Kennzahlen und die nutzbaren gespeicherten Abfragen |
Was heute enthalten ist und was als Nächstes kommt
Die Roadmap-Punkte sind bewusst additiv — neue Datenquellen, Widget-Typen und Exportdienste —, keiner davon wird Sie also zu einer Migration zwingen. Sie stehen als Roadmap da, nicht als Funktionen, damit Sie auf Basis dessen kaufen, was heute im Paket ist.
| Funktion | Status |
|---|---|
| Dashboards: anlegen, duplizieren, als Standard festlegen, exportieren und importieren | Verfügbar |
| Skalierbares Drag-and-drop-Raster mit automatischem Speichern | Verfügbar |
| KPI, Tabelle und der vollständige ECharts-Diagrammsatz | Verfügbar |
| Visuelle Widget-Konfiguration ohne SQL | Verfügbar |
| Wiederverwendung gespeicherter Abfragen und Board-Erzeugung mit einem Klick | Verfügbar |
| Globale Filter, die das ganze Board aktualisieren | Verfügbar |
| Absprung vom Diagramm in die Ticketliste | Verfügbar |
| Berechtigungsgeprüfte SQL-Aggregation und Caching je Benutzer | Verfügbar |
| Freigabe, Vorlagen, helles und dunkles Thema | Verfügbar |
| Versions- und datenbankübergreifend, serverseitige Rückfallebene | Verfügbar |
| Export als PDF, PNG und Excel | Geplant |
| Hintergrundjobs für sehr schwere Berichte | Geplant |
| Live-Aktualisierung über WebSocket | Geplant |
| Geplante Schnappschüsse per E-Mail | Geplant |
| Kiosk- / Wandanzeige-Modus | Geplant |
| KI-Berichtsbaukasten in natürlicher Sprache | Geplant |
| Widgets für Kalender, Burndown und Gantt-Zusammenfassung | Geplant |
In drei Schritten installiert
Erfordert Shell-Zugriff und die Möglichkeit, Rake-Tasks auszuführen. Sichern Sie vor jeder Plugin-Installation Ihre Daten.
cd /path/to/redmine # unzip the package from your email or download link unzip redmine_charts-1.0.0.zip -d plugins/ bundle install
bundle exec rake redmine:plugins:migrate NAME=redmine_charts RAILS_ENV=production # optional: the built-in dashboard templates bundle exec rake redmine_charts:seed_templates RAILS_ENV=production touch tmp/restart.txt
# Project → Settings → Modules → Charts & Dashboards # then grant the dashboard permissions to the roles that need them # a Dashboards entry appears in the top menu for anyone who holds one
Verändert oder überschreibt es Redmine-Core-Dateien?
Brauche ich Node.js oder einen Build-Schritt für die Installation?
Funktionieren meine bestehenden gespeicherten Abfragen, auch die komplizierten?
Kann jemand Zahlen aus einem Projekt sehen, auf das er keinen Zugriff hat?
Welche Datenbanken werden unterstützt?
Auf welchen Redmine- und Rails-Versionen läuft es?
Können wir eigene Datenquellen oder Diagrammtypen ergänzen?
Was fehlt in Version 1.0 bewusst?
Preise
Ein Server
Eine Redmine-Instanz · unbegrenzt viele Benutzer · 12 Monate Updates.
Mehrere Server
Unbegrenzt viele Redmine-Server · unbegrenzt viele Benutzer · 12 Monate Updates.