Version 1.1.0 · Redmine 5.1 and 6 · GPLv2
This manual covers installation, configuration and daily use of the atori Kanban Board plugin.
The plugin adds a per-project Kanban view that maps directly onto the issue statuses defined in your Redmine instance. There is no parallel workflow, no separate status model and no shadow data: columns are issue statuses, cards are issues, and every change on the board is a regular Redmine operation with the corresponding journal entry.
Key concepts:
IssueStatus. Columns can be hidden or reordered inside the board settings; hidden columns still exist in Redmine but do not appear on the board.IssueQuery. Using a saved query gives you arbitrarily complex filtering without reimplementing a query language in the plugin.cd /path/to/redmine
unzip at_kanbanboard-1.2.0.zip -d plugins/
bundle exec rake redmine:plugins:migrate NAME=at_kanbanboard RAILS_ENV=production
# restart Redmine (passenger/puma/systemd unit)
cd /path/to/redmine
git clone <repo-url> plugins/at_kanbanboard
bundle exec rake redmine:plugins:migrate NAME=at_kanbanboard RAILS_ENV=production
# restart Redmine
After restart, log in as an administrator and open Administration → Plugins. The Kanban Board plugin should appear with version 1.1.0 and no error banner.
cd /path/to/redmine
bundle exec rake redmine:plugins:migrate NAME=at_kanbanboard VERSION=0 RAILS_ENV=production
rm -rf plugins/at_kanbanboard
# restart Redmine
The rake task above reverses all plugin migrations, dropping the three tables the plugin owns (kanban_boards, kanban_board_columns, kanban_issue_positions). Existing Redmine data (issues, statuses, queries) is untouched.
Kanban is implemented as a project module and is off by default.
The plugin exposes three independent permissions under Administration → Roles and permissions → Kanban board:
| Permission | Scope | Typical role |
|---|---|---|
| View Kanban board | See the board, read-only | Reporter |
| Edit issues on Kanban board | Drag & drop, reorder within columns | Developer |
| Manage Kanban board | Change board settings (card source, swimlanes, WIP, column visibility) | Manager |
Separating view from edit lets you give read-only stakeholders access without risking accidental status changes.
The first time any user with the View Kanban board permission opens the Kanban tab, the board record is created automatically. One column per issue status is generated in the order Redmine defines; closed statuses are included but can be hidden later from the board settings.
Inside a project with the Kanban module enabled, a Kanban entry appears in the project menu (after Issues). Clicking it renders the board with the project's current issues arranged by status.
Users with Edit issues on Kanban board can drag a card from one column to another. The drop triggers a status update on the underlying issue, which goes through Redmine's normal workflow checks – meaning workflow restrictions defined per role and tracker are respected. A journal entry is written exactly as if the status had been changed through the standard issue form.
Reordering cards within a column is saved to the plugin's own position table (kanban_issue_positions) and does not touch issue data. This is how you indicate priority on the board without using the priority field.
By default the board shows all issues of the project. To narrow the set:
The board now shows only the issues that the saved query returns. Use this to scope the board to a sprint, a release, an area owner, or any other dimension you already express with queries.
Under board settings, choose a Swimlane field. Supported values:
An empty selection disables swimlanes and renders the default single-row layout. Swimlanes are purely a view concern; turning them on or off does not change issue data.
Per column, set a positive integer limit. When the visible card count in that column exceeds the limit the column header shows a warning. The plugin deliberately does not block further moves – a hard block tends to cause work-arounds outside the tool, undermining the reason you set the limit in the first place.
To disable a WIP limit on a column, clear the field.
In board settings:
Every card move is a status change on the issue, so the full audit trail lives in the issue's journal – no separate log needs to be consulted or exported. Swimlane group changes follow the same path (the underlying field is updated).
Drag & drop does nothing / reverts. Verify that the logged-in user has the Edit issues on Kanban board permission and that Redmine's workflow allows the transition from the source status to the target status for that user's role. Rejected transitions snap the card back to its original column.
A column is missing that I know has issues. Open board settings and check whether the column is marked as hidden or whether Hide closed statuses is active. Status columns are created for every existing IssueStatus, but hidden ones are invisible by design.
Cards don't appear although issues exist. If a saved query is configured as the card source, check the query's filters – cards that fall outside the query are not shown. Remove the query in board settings to return to the default (all project issues).
Performance on large projects. The board renders every card it finds. For projects with thousands of open issues, define a saved query that limits the set to what is actually in play (e.g. "this sprint" or "open + assigned to team"), and use that as the card source.
A new issue status I just created isn't on the board. The column list is reconciled on every board load. Reload the board page (or the project) and the new column will appear at the end of the sequence.
Support is included for twelve months from the date of purchase and covers bug reports, configuration questions and compatibility issues.
E-mail: support@atori.de Initial response: within 48 hours on business days.
When reporting issues, please include:
log/production.log, if available