Redmine Dashboards

Dashboards

5.0 (0)·New installs

Dashboards built out of the saved queries you already have — a drag-and-drop grid of KPI tiles, tables and fifteen chart types, aggregated in SQL and scoped to whatever the person looking is allowed to see.

$199 / single server

Multiple servers: $399

5-working-day refund12 months updatesSource included

A Redmine Charts dashboard inside Redmine 6: a 10,000-issue KPI tile, a project donut, issues-by-priority bars, a status donut and a created-per-month line chart. — A live dashboard KPI tiles, donuts, bar and line charts on one board — every figure aggregated in SQL from Redmine’s own permission-scoped data.

Widget types: 23
Chart variants: 15
Redmine: 4 · 5 · 6 · 7
Databases: MySQL, MariaDB, PostgreSQL
Core patches: None

Drag-and-drop builder

A resizable, reorderable grid that saves itself as you work. Arrange KPIs, charts and tables until the board tells the story you need — no layout file, no page reload.

Fifteen chart types

Bar, horizontal, stacked, line, multi-line, area, pie, donut, radar, polar, gauge, funnel, heatmap, treemap and progress ring — drawn with Apache ECharts, in light and dark.

Your saved queries, visualised

Point a widget at a saved query and it inherits that filter — custom fields, watchers and sub-projects included. Or turn the query into a whole board in one click.

Aggregated in SQL

GROUP BY, COUNT, SUM and AVG run in the database, so a hundred thousand issues get counted rather than instantiated. Results cache per user, widget and active filters.

Scoped to the viewer

Every read starts from Issue.visible(user), TimeEntry.visible(user) and Query.visible(user), so no chart can total a project the person reading it is not a member of.

Filters, refresh and drill-down

One filter bar re-scopes the whole board, a per-dashboard interval keeps a wall display current, and every bar, slice and cell clicks through to the issue list behind it.

See it running inside Redmine

Every screenshot here comes from a stock Redmine 6 install with the plugin dropped into plugins/. The dashboards sit under Redmine’s own header and menus, because that’s where they run.

Build a board

The Add widget dialog: widget type, data source, optional saved query, measure and aggregation, chosen from dropdowns. — Add a widget Pick a widget type, a data source and an optional saved query, then choose the measure and aggregation. Nobody writes SQL.

Widgets

The widget type picker listing fifteen ECharts variants, KPI and table, plus Markdown, notes, HTML, iframe, activity feed and recent issues. — 23 widget types Fifteen ECharts variants plus KPI, table and six content widgets — Markdown, notes, HTML, iframe, activity feed and recent issues.

Share and switch

The dashboard sharing dialog with private, shared and public visibility, and pickers for roles, groups and projects. — Sharing Keep a board private, share it with specific roles, groups or projects, or open it to every logged-in user — resolved through Redmine memberships.

The toolbar dashboard switcher listing every visible board, with options to set a default, export as JSON or create a new board. — Switch boards The toolbar switcher lists every board you can see. Pin one as your default, export it as JSON, or start a new one.

The query is already the report

Nothing here asks you to describe your data a second time. Filter an issue list the way you always have, save it, and that saved query becomes the scope a widget aggregates — the same relation Redmine uses to render the list itself.

One saved query, three ways onto a board
Step	What you do	What you get
1. Save a query	Filter the issue list — custom fields, watchers, sub-projects — and hit Save	A named query, shared with whoever you shared it with
2. Point a widget at it	Pick that query in the widget dialog	Data source and a sensible default grouping, derived for you
3. Or generate the whole board	Click From query	A dashboard of KPI tiles and charts bound to it, in one request

Configured from dropdowns, not SQL

A widget is a source, a dimension, a measure and an aggregation. Group issues by status, priority, tracker, assignee or any date field bucketed into days, weeks, months or years; count them, sum estimated hours, or average the done ratio. Nobody on the team writes SQL to get a chart — and because there is no SQL to write, there is no query that can reach past the permissions of the person reading it.

The From query dialog: choose a saved Redmine query to generate a dashboard of KPIs and charts bound to its filters. — From a saved query Choose any saved query and get a ready-made board of KPIs and charts — status, priority, assignee, trend and a table — bound to its filters.

Configure every widget from one form

Every widget, whether it’s a KPI, a bar or a donut, is set up in the same short form: a title and a type, a data source, an optional saved query for filters, a measure, and a grouping with Top-N. Change the type and the form adapts.

Configure widget form for a KPI: title Total issues, data source Issues, saved query, measure Issue count, function count. — KPI tile One number: a measure and an aggregation over a saved query.

Configure widget form for a bar chart: Issues by priority, grouped by Priority, Top N 20. — Bar chart Group by any dimension, such as priority, and cap the long tail with Top-N.

Configure widget form for a donut chart: Issues by status, grouped by Status. — Donut chart The same fields with a different type. Switching the chart keeps your data settings.

Redmine Charts plugin settings: enable caching, cache expiration 300 seconds, default theme Light, auto-refresh interval 0. — Plugin settings Caching, cache TTL, default theme and auto-refresh, on Redmine’s own settings screen.

One settings page for admins

Under Administration › Plugins › Redmine Charts you set per-user result caching, the cache TTL (5–86400 seconds, default 300), the default light or dark theme, and a default auto-refresh interval, where 0 turns it off. The page is Redmine’s own plugin settings screen.

23 widget types, and room for yours

Every type is registry-driven metadata, so the configuration UI builds itself from the widget's own declaration rather than from a hand-written form per chart.

The catalogue that ships in the box
Family	Types	Configured with
Charts	Bar, horizontal bar, stacked bar, line, multi-line, area, pie, donut, radar, polar, gauge, funnel, heatmap, treemap, progress ring	Source, dimension, measure, aggregation
KPI / number	A single aggregated figure with its own filter	count · sum · avg · min · max
Table	A paginated grid over the same permission-scoped data	Column picker and filters
Content	Markdown, notes, HTML, iframe, activity feed, recent issues	Free text, or one of Redmine's own feeds

Drawn with Apache ECharts

Fifteen variants, themed for light and dark, redrawn on resize and still legible on a wall display. The bundle ships pre-built inside the package, so installing the plugin needs no Node and no build step.

Every segment drills down

Clicking a bar, a slice or a heatmap cell opens the Redmine issue list filtered to exactly those issues. The numbers stay auditable, because you can always land on the rows behind them.

Global filters and auto-refresh

One filter bar re-scopes every widget on the board at once, and a per-dashboard refresh interval keeps a screen in the corridor current. Zero turns refreshing off.

Templates and blueprints

Save a board as a reusable template, duplicate it per team, or export it as a JSON blueprint and import it into another instance — staging to production without rebuilding it by hand.

One plugin, a board for every team

A delivery lead, a support desk and a single developer each built these in minutes from saved queries they already had.

Full-length dashboard: KPI, donuts, priority bars, monthly trend, workload by assignee and a paginated issue table. — Portfolio overview KPI, donuts, trend, workload by assignee and a paginated issue table.

Issues assigned to me dashboard with a KPI, an area chart and a status donut. — Issues assigned to me A personal board with an area chart and a status donut.

Created issues dashboard with a KPI, a tracker donut and priority bars. — Created issues Tracker mix, priority split and status at a glance.

Support desk dashboard: KPI tiles for total issues and spent time, a status donut, bars by priority, sub-tracker and module, and a created-per-month line chart. — Support desk Tickets, time spent, priority, sub-tracker and workload by module for one support period.

A full-year support dashboard: KPI tiles for total issues and spent time, a status donut, bars by priority, module and sub-tracker, and a created-per-month line chart. — The support year in numbers Ticket volume, hours logged and the priority and module split, with the month-by-month trend.

Two sources built in, and yours beside them

Issues and time entries ship with their dimensions and measures registered up front, both behind Redmine's own visibility scopes. A source added by another plugin is treated identically.

Source	Dimensions	Measures
Issues	Status, priority, tracker, project, assignee, author, category, version, created, updated, due date	Issue count, estimated hours, done ratio
Time entries	Project, user, activity, spent on	Hours, entry count
Your own	Whatever you register	Whatever you register

Extending it is registration, not patching

A data source is a class with a name, its dimensions, its measures and a permission-scoped base_scope; a widget type is a hash. Register either one from your own plugin's init.rb with RedmineCharts.register_data_source or register_widget_type, and it appears in the configuration UI immediately — inheriting filtering, caching and drill-down. Nothing in this plugin is edited to make that work.

Nobody aggregates what they can't read

A dashboard is a fast way to leak a number, so every read starts from the viewer's own scope rather than ending with a check against it.

Visibility first, grouping second

Issue.visible(user), TimeEntry.visible(user) and Query.visible(user) constrain the relation before a single row is counted. A total from a project you are not a member of cannot appear in any widget, because those rows were never in the set.

Four granular permissions

View dashboards, create them, manage all of them, manage templates — each assignable per role. And all of it stays off until someone enables the Charts & Dashboards module for that project.

Sharing through memberships

Grant a board to users, groups, roles or whole projects. Every request re-resolves viewable_by? and editable_by? through Redmine's own memberships, rather than through a parallel access list that drifts out of step.

Nothing leaves the server

The frontend talks only to this plugin's JSON API on your own Redmine, over the session and CSRF token that are already there. No external service, no licence phone-home, no telemetry.

Built to survive a big instance

Counting a hundred thousand issues should not mean loading a hundred thousand objects. Here it doesn't.

What happens when a board is opened
Concern	How it is handled
Aggregation	GROUP BY, COUNT, SUM and AVG run in SQL — rows are never instantiated just to be counted
Wide dimensions	Top-N folding keeps the payload small when a dimension has thousands of values
Repeat views	Results cached per user, widget mtime and active filters through Rails.cache; the TTL is a setting and Redis works as-is
One slow widget	Widgets load independently, so a single heavy query never holds the whole board hostage
A missing JS bundle	Rails renders every widget's data server-side as a fallback, so the page degrades instead of going blank

Deliberately portable, not accidentally

Cross-version and cross-database support is designed in — migrations, JSON storage and date bucketing were all written to survive the differences.

Concern	Supported	How
Redmine	4.x, 5.x, 6.x, 7.x	Declares requires_redmine version_or_higher 4.0.0, with no core overrides to drift out of date
Rails	5.2 → 8.0	Migrations target the 5.2 baseline that every release up to 8.0 understands
Ruby	2.5+	Matches the minimum Redmine 4 requirement
Databases	MySQL, MariaDB, PostgreSQL	JSON lives in plain text columns — identical DDL everywhere — with a serializer that picks the right form per Rails version
Date grouping	Day, week, month, year	Groups on a portable CAST(col AS DATE), then folds into buckets in Ruby — no vendor-specific SQL
Re-running migrations	Safe	Written defensively, so an interrupted upgrade can be replayed

Scriptable from the first day

Every endpoint lives under /redmine_charts/api, returns JSON and enforces exactly the permissions the UI does — so boards can be provisioned from CI or generated one per team.

Method	Path	What it does
GET	/dashboards	Every dashboard visible to the caller
POST	/dashboards	Create one
GET	/dashboards/:id	Fetch a dashboard with its widgets
PATCH	/dashboards/:id	Update name, layout or settings
POST	/dashboards/:id/duplicate	Clone it, widgets included
GET	/dashboards/:id/export	Export a JSON blueprint
POST	/dashboards/import	Create a board from a blueprint
POST	/dashboards/:id/widgets	Add a widget
GET	/widgets/:id/data	Aggregated, permission-scoped widget data
GET	/meta/data_sources	Sources, dimensions, measures and the saved queries you can use

What ships today, and what’s next

The roadmap items are additive by design — new data sources, widget types and export services — so none of them will ask you to migrate anything. They’re listed as roadmap, not as features, so you can buy on what’s in the box today.

Capability	Status
Dashboards: create, duplicate, set default, export and import	Live
Drag-and-drop resizable grid with auto-save	Live
KPI, table and the full ECharts chart set	Live
Visual no-SQL widget configuration	Live
Saved-query reuse and one-click board generation	Live
Global filters that refresh the whole board	Live
Chart → issue-list drill-down	Live
Per-user, permission-scoped SQL aggregation and caching	Live
Sharing, templates, light and dark themes	Live
Cross-version, cross-database, server-side fallback	Live
PDF, PNG and Excel export	Planned
Background jobs for very heavy reports	Planned
WebSocket live updates	Planned
Scheduled and emailed snapshots	Planned
Kiosk / wallboard mode	Planned
AI natural-language report builder	Planned
Calendar, burndown and gantt-summary widgets	Planned

Install in three steps

Requires shell access and the ability to run rake tasks. Always back up before installing a plugin.

Unpack into your plugins folder

cd /path/to/redmine
# unzip the package from your email or download link
unzip redmine_charts-1.0.0.zip -d plugins/
bundle install

Migrate, seed the templates, restart

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

Enable it where you want it

# 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

Does it patch or override any Redmine core files?

No. It registers a project module, permissions, menu entries and routes through the documented Redmine::Plugin.register API, and adds its own controllers, models and migrations. Uninstalling means deleting the plugin directory and rolling back its migrations — nothing in core has been touched to be put back.

Do I need Node.js or a build step to install it?

No. A pre-built frontend bundle ships inside the package, so the plugin works as soon as the migrations have run and Redmine has restarted. Node is only needed if you want to change the React source and rebuild it yourself, which the package supports but does not require.

Will my existing saved queries work, including the complicated ones?

Yes. Aggregation runs on top of the query's own scope — the exact relation Redmine uses to render the issue list — so filters that need custom joins, such as custom fields, watchers and sub-projects, carry over unchanged. Picking a query also derives the widget's data source and a default grouping, so most widgets are two clicks.

Can someone see numbers from a project they have no access to?

No. Every aggregation is built on Redmine's own visibility scopes for the current user before any grouping happens, and each dashboard additionally re-checks viewable_by? on every request. An out-of-scope issue is never part of a count, so there is no total to leak.

Which databases are supported?

MySQL, MariaDB and PostgreSQL, with identical DDL on all three. JSON is stored in plain text columns, and date grouping runs on a portable CAST(col AS DATE) that is folded into day, week, month or year buckets in Ruby — so there is no vendor-specific SQL and no “PostgreSQL only” asterisk on any feature.

Which Redmine and Rails versions does it run on?

Redmine 4, 5, 6 and 7, on Rails 5.2 through 8.0 and Ruby 2.5 or newer. Migrations target the [5.2] baseline every one of those releases understands and are written defensively, so an interrupted upgrade can simply be re-run. Because there are no core overrides, there is nothing to drift out of date when you upgrade Redmine.

Can we add our own data sources or chart types?

Yes, from a separate plugin and with no changes here. Subclass RedmineCharts::DataSource and call register_data_source for a new source, or register_widget_type for a new chart. Both appear in the configuration UI immediately and inherit filtering, caching and drill-down — which is also how the two built-in sources are registered.

What is deliberately not in version 1.0?

PDF, PNG and Excel export, background jobs for very heavy reports, scheduled email snapshots, live updates over WebSocket and a kiosk mode are designed for but not built — so you can buy on what is in the box today. All of them are additive: none will ask you to migrate a dashboard you have already built.