Redmine Dashboards

Dashboards

5.0 (0)·New installations

Des tableaux de bord construits à partir des requêtes enregistrées que vous avez déjà — une grille en glisser-déposer de tuiles d’indicateurs, de tableaux et de quinze types de graphiques, agrégés en SQL et limités à ce que la personne qui regarde a le droit de voir.

$199 / un serveur

Plusieurs serveurs: $399

Remboursement sous 5 jours ouvrés12 mois de mises à jourSources incluses

Un tableau de bord Redmine Charts dans Redmine 6 : une tuile KPI de 10 000 demandes, un anneau par projet, des barres par priorité, un anneau par statut et une courbe des demandes créées par mois. — Un tableau de bord en direct Tuiles KPI, anneaux, barres et courbes sur un même tableau — chaque chiffre agrégé en SQL à partir des données de Redmine, filtrées par les droits.

Types de widgets: 23
Variantes de graphiques: 15
Redmine: 4 · 5 · 6 · 7
Bases de données: MySQL, MariaDB, PostgreSQL
Correctifs du cœur: Aucun

Construction en glisser-déposer

Une grille redimensionnable et réorganisable qui s’enregistre au fil de votre travail. Disposez indicateurs, graphiques et tableaux jusqu’à ce que le tableau de bord raconte ce qu’il doit — sans fichier de mise en page, sans rechargement.

Quinze types de graphiques

Barres, barres horizontales, barres empilées, courbe, multi-courbes, aires, camembert, anneau, radar, polaire, jauge, entonnoir, carte de chaleur, treemap et anneau de progression — dessinés avec Apache ECharts, en clair comme en sombre.

Vos requêtes enregistrées, mises en image

Pointez un widget sur une requête enregistrée et il en hérite le filtre — champs personnalisés, observateurs et sous-projets compris. Ou transformez la requête en tableau de bord complet en un clic.

Agrégé en SQL

GROUP BY, COUNT, SUM et AVG s’exécutent dans la base : cent mille demandes sont comptées, jamais instanciées. Les résultats sont mis en cache par utilisateur, par widget et par filtres actifs.

Limité à celui qui regarde

Chaque lecture part de Issue.visible(user), TimeEntry.visible(user) et Query.visible(user) : aucun graphique ne peut totaliser un projet dont le lecteur n’est pas membre.

Filtres, rafraîchissement et exploration

Une barre de filtres recadre tout le tableau de bord, un intervalle propre à chaque tableau garde un écran mural à jour, et chaque barre, part et cellule renvoie à la liste des demandes correspondante.

Voyez-le tourner dans Redmine

Chaque capture provient d’une installation standard de Redmine 6, avec le plugin simplement déposé dans plugins/. Les tableaux de bord s’affichent sous l’en-tête et les menus de Redmine, parce que c’est là qu’ils s’exécutent.

Construire un tableau

Mode édition d’un tableau de bord : chaque widget affiche des poignées de déplacement et des coins de redimensionnement, et la disposition est enregistrée automatiquement. — Mode édition Activez l’interrupteur Modifier et chaque widget devient déplaçable et redimensionnable. La disposition s’enregistre au fil de l’eau.

Widgets

Le sélecteur de type de widget, avec quinze variantes ECharts, KPI et tableau, ainsi que Markdown, notes, HTML, iframe, flux d’activité et demandes récentes. — 23 types de widgets Quinze variantes ECharts, plus KPI, tableau et six widgets de contenu — Markdown, notes, HTML, iframe, flux d’activité et demandes récentes.

Le menu propre à un widget, ouvert sur un tableau de bord, avec les actions actualiser, configurer et supprimer. — Actions du widget Chaque widget se charge seul et possède son propre menu — actualisez un graphique sans recharger le reste du tableau.

Partager et basculer

La boîte de dialogue de partage d’un tableau de bord, avec les visibilités privée, partagée et publique, et des sélecteurs de rôles, de groupes et de projets. — Partage Gardez un tableau privé, partagez-le avec des rôles, groupes ou projets précis, ou ouvrez-le à tout utilisateur connecté — le tout résolu via les appartenances de Redmine.

Le sélecteur de tableaux de bord de la barre d’outils, qui liste chaque tableau visible, avec des options pour en définir un par défaut, l’exporter en JSON ou en créer un nouveau. — Changer de tableau Le sélecteur de la barre d’outils liste tous les tableaux que vous pouvez voir. Épinglez-en un par défaut, exportez-le en JSON ou créez-en un nouveau.

La requête est déjà le rapport

Rien ici ne vous demande de décrire vos données une deuxième fois. Filtrez une liste de demandes comme vous l’avez toujours fait, enregistrez-la, et cette requête devient le périmètre qu’un widget agrège — la relation même que Redmine utilise pour afficher la liste.

Une requête enregistrée, trois chemins vers un tableau de bord
Étape	Ce que vous faites	Ce que vous obtenez
1. Enregistrer une requête	Filtrer la liste des demandes — champs personnalisés, observateurs, sous-projets — puis cliquer sur Enregistrer	Une requête nommée, visible par ceux avec qui vous l’avez partagée
2. Y pointer un widget	Choisir cette requête dans la boîte de dialogue du widget	La source de données et un regroupement par défaut, déduits pour vous
3. Ou générer tout le tableau	Cliquer sur « Depuis la requête »	Un tableau de bord de tuiles d’indicateurs et de graphiques qui lui sont liés, en une seule requête

Configuré depuis des listes déroulantes, pas depuis du SQL

Un widget, c’est une source, une dimension, une mesure et une agrégation. Regroupez les demandes par statut, priorité, tracker, assigné ou n’importe quel champ date découpé en jours, semaines, mois ou années ; comptez-les, additionnez les heures estimées ou faites la moyenne du taux d’avancement. Personne dans l’équipe n’écrit de SQL pour obtenir un graphique — et comme il n’y a pas de SQL à écrire, aucune requête ne peut dépasser les droits de la personne qui la lit.

La boîte de dialogue Depuis la requête : choisir une requête Redmine enregistrée pour générer un tableau de bord de KPI et de graphiques liés à ses filtres. — Depuis une requête enregistrée Choisissez n’importe quelle requête enregistrée et obtenez un tableau prêt à l’emploi de KPI et de graphiques — statut, priorité, assigné, tendance et un tableau — lié à ses filtres.

Chaque widget se configure depuis un seul formulaire

Qu’il s’agisse d’un KPI, de barres ou d’un anneau, chaque widget se règle dans le même formulaire court : un titre et un type, une source de données, une requête enregistrée facultative pour les filtres, une mesure, et un regroupement avec Top-N. Changez le type, le formulaire s’adapte.

Formulaire Configurer le widget pour un KPI : titre Total des demandes, source de données Demandes, requête enregistrée, mesure Nombre de demandes, fonction count. — Tuile KPI Un seul chiffre : une mesure et une agrégation sur une requête enregistrée.

Formulaire Configurer le widget pour un graphique en barres : Demandes par priorité, regroupées par Priorité, Top N 20. — Graphique en barres Regroupez selon n’importe quelle dimension, la priorité par exemple, et coupez la traîne avec Top-N.

Formulaire Configurer le widget pour un graphique en anneau : Demandes par statut, regroupées par Statut. — Graphique en anneau Les mêmes champs, un autre type. Changer de graphique conserve vos réglages de données.

Configuration du plugin Redmine Charts : cache activé, expiration du cache 300 secondes, thème par défaut Clair, intervalle de rafraîchissement automatique 0. — Configuration du plugin Cache, TTL du cache, thème par défaut et rafraîchissement automatique, sur l’écran de configuration de Redmine lui-même.

Une seule page de réglages pour les administrateurs

Dans Administration › Plugins › Redmine Charts, vous réglez le cache des résultats par utilisateur, le TTL du cache (5–86400 secondes, 300 par défaut), le thème clair ou sombre par défaut et un intervalle de rafraîchissement automatique par défaut, 0 le désactivant. C’est l’écran de configuration des plugins de Redmine lui-même.

23 types de widgets, et de la place pour les vôtres

Chaque type est une métadonnée déposée dans un registre : l’interface de configuration se construit à partir de la déclaration du widget, et non d’un formulaire écrit à la main pour chaque graphique.

Le catalogue livré dans la boîte
Famille	Types	Configuré avec
Graphiques	Barres, barres horizontales, barres empilées, courbe, multi-courbes, aires, camembert, anneau, radar, polaire, jauge, entonnoir, carte de chaleur, treemap, anneau de progression	Source, dimension, mesure, agrégation
Indicateur / nombre	Un seul chiffre agrégé, avec son propre filtre	count · sum · avg · min · max
Tableau	Une grille paginée sur les mêmes données filtrées par les droits	Sélecteur de colonnes et filtres
Contenu	Markdown, notes, HTML, iframe, flux d’activité, demandes récentes	Texte libre, ou l’un des flux de Redmine

Dessiné avec Apache ECharts

Quinze variantes, pensées pour le clair et le sombre, redessinées au redimensionnement et encore lisibles sur un écran mural. Le bundle est livré déjà compilé : l’installation ne demande ni Node ni étape de build.

Chaque segment explore

Cliquer sur une barre, une part ou une cellule ouvre la liste des demandes Redmine filtrée exactement sur celles-ci. Les chiffres restent vérifiables, puisque vous pouvez toujours atterrir sur les lignes qui les composent.

Filtres globaux et rafraîchissement

Une barre de filtres recadre tous les widgets d’un coup, et un intervalle propre à chaque tableau de bord garde à jour l’écran du couloir. Zéro désactive le rafraîchissement.

Modèles et plans

Enregistrez un tableau comme modèle réutilisable, dupliquez-le par équipe, ou exportez-le en plan JSON pour l’importer dans une autre instance — de la préproduction à la production, sans le reconstruire à la main.

Un plugin, un tableau pour chaque équipe

Une responsable de livraison, un support et un développeur seul ont chacun construit ceux-ci en quelques minutes, à partir de requêtes enregistrées qu’ils avaient déjà.

Tableau de bord pleine longueur : KPI, anneaux, barres par priorité, tendance mensuelle, charge par assigné et un tableau paginé de demandes. — Vue d’ensemble du portefeuille KPI, anneaux, tendance, charge par assigné et un tableau paginé de demandes.

Tableau de bord Demandes qui me sont assignées, avec un KPI, un graphique en aires et un anneau par statut. — Demandes qui me sont assignées Un tableau personnel avec un graphique en aires et un anneau par statut.

Tableau de bord Demandes créées, avec un KPI, un anneau par tracker et des barres par priorité. — Demandes créées Répartition par tracker, par priorité et par statut, d’un coup d’œil.

Tableau de bord du support : des tuiles KPI pour le total des demandes et le temps passé, un anneau par statut, des barres par priorité, par sous-tracker et par module, et une courbe des demandes créées par mois. — Vue d’ensemble du support Demandes, temps passé, priorité, sous-tracker et charge par module sur une période de support.

Tableau de bord du support sur une année complète : des tuiles KPI pour le total des demandes et le temps passé, un anneau par statut, des barres par priorité, par module et par sous-tracker, et une courbe des demandes créées par mois. — L’année de support en chiffres Volume de demandes, temps passé et répartition par priorité et par module, avec l’évolution mois par mois.

Deux sources intégrées, et la vôtre à côté

Les demandes et les temps passés arrivent avec leurs dimensions et leurs mesures déjà déclarées, toutes deux derrière les périmètres de visibilité de Redmine. Une source ajoutée par un autre plugin est traitée à l’identique.

Source	Dimensions	Mesures
Demandes	Statut, priorité, tracker, projet, assigné, auteur, catégorie, version, création, mise à jour, échéance	Nombre de demandes, heures estimées, taux d’avancement
Temps passés	Projet, utilisateur, activité, date	Heures, nombre d’entrées
La vôtre	Ce que vous déclarez	Ce que vous déclarez

Étendre, c’est déclarer, pas corriger

Une source de données est une classe avec un nom, ses dimensions, ses mesures et un base_scope filtré par les droits ; un type de widget est un hash. Déclarez l’un ou l’autre depuis le init.rb de votre propre plugin avec RedmineCharts.register_data_source ou register_widget_type, et il apparaît immédiatement dans l’interface de configuration — en héritant du filtrage, du cache et de l’exploration. Rien n’est modifié dans ce plugin-ci pour cela.

Personne n’agrège ce qu’il n’a pas le droit de lire

Un tableau de bord est un moyen rapide de laisser fuiter un chiffre : chaque lecture part donc du périmètre de la personne qui regarde, au lieu de se terminer par une vérification.

La visibilité d’abord, le regroupement ensuite

Issue.visible(user), TimeEntry.visible(user) et Query.visible(user) restreignent la relation avant qu’une seule ligne ne soit comptée. Un total venant d’un projet dont vous n’êtes pas membre ne peut apparaître dans aucun widget : ces lignes n’ont jamais fait partie de l’ensemble.

Quatre permissions distinctes

Consulter les tableaux de bord, en créer, tous les gérer, gérer les modèles — chacune attribuable par rôle. Et tout reste désactivé tant que le module Tableaux de bord n’est pas activé pour le projet.

Un partage qui passe par les appartenances

Donnez accès à un tableau à des utilisateurs, des groupes, des rôles ou des projets entiers. Chaque requête réévalue viewable_by? et editable_by? via les appartenances de Redmine, et non via une liste d’accès parallèle qui finit par diverger.

Rien ne quitte le serveur

Le frontend ne parle qu’à l’API JSON de ce plugin, sur votre propre Redmine, avec la session et le jeton CSRF déjà en place. Aucun service externe, aucun appel de licence, aucune télémétrie.

Conçu pour tenir sur une grosse instance

Compter cent mille demandes ne devrait pas obliger à charger cent mille objets. Ici, ce n’est pas le cas.

Ce qui se passe à l’ouverture d’un tableau de bord
Sujet	Comment c’est traité
Agrégation	GROUP BY, COUNT, SUM et AVG s’exécutent en SQL — aucune ligne n’est instanciée juste pour être comptée
Dimensions très larges	Le repli Top-N garde la réponse petite quand une dimension compte des milliers de valeurs
Consultations répétées	Résultats mis en cache par utilisateur, date de modification du widget et filtres actifs via Rails.cache ; le TTL est un réglage et Redis fonctionne tel quel
Un widget lent	Les widgets se chargent indépendamment : une requête lourde ne retient jamais tout le tableau
Bundle JS absent	Rails rend côté serveur les données de chaque widget en repli : la page se dégrade au lieu de rester blanche

Portable par conception, pas par hasard

La compatibilité entre versions et entre bases de données est pensée dès le départ — migrations, stockage JSON et regroupement par date ont tous été écrits pour résister aux différences.

Sujet	Pris en charge	Comment
Redmine	4.x, 5.x, 6.x, 7.x	Déclare requires_redmine version_or_higher 4.0.0, sans surcharge du cœur susceptible de se périmer
Rails	5.2 → 8.0	Les migrations visent la base 5.2, que toutes les versions jusqu’à 8.0 comprennent
Ruby	2.5+	Correspond au minimum requis par Redmine 4
Bases de données	MySQL, MariaDB, PostgreSQL	Le JSON est stocké dans de simples colonnes texte — DDL identique partout — avec un sérialiseur qui choisit la bonne forme selon la version de Rails
Regroupement par date	Jour, semaine, mois, année	Regroupe sur un CAST(col AS DATE) portable, puis replie en intervalles côté Ruby — aucun SQL spécifique à un éditeur
Relancer les migrations	Sans risque	Écrites de façon défensive, pour qu’une mise à jour interrompue puisse être rejouée

Scriptable dès le premier jour

Chaque endpoint vit sous /redmine_charts/api, renvoie du JSON et applique exactement les droits de l’interface — un tableau peut donc être provisionné depuis la CI ou généré par équipe.

Méthode	Chemin	Ce qu’il fait
GET	/dashboards	Tous les tableaux de bord visibles par l’appelant
POST	/dashboards	En créer un
GET	/dashboards/:id	Récupérer un tableau et ses widgets
PATCH	/dashboards/:id	Modifier le nom, la disposition ou les réglages
POST	/dashboards/:id/duplicate	Le cloner, widgets compris
GET	/dashboards/:id/export	Exporter un plan JSON
POST	/dashboards/import	Créer un tableau à partir d’un plan
POST	/dashboards/:id/widgets	Ajouter un widget
GET	/widgets/:id/data	Données de widget agrégées et filtrées par les droits
GET	/meta/data_sources	Sources, dimensions, mesures et requêtes enregistrées utilisables

Ce qui est livré aujourd’hui, et ce qui arrive

Les éléments de la feuille de route sont additifs par conception — nouvelles sources de données, types de widgets et services d’export — aucun ne vous demandera donc de migrer quoi que ce soit. Ils sont présentés comme feuille de route et non comme fonctionnalités, pour que vous achetiez sur la base de ce qui est dans la boîte aujourd’hui.

Fonctionnalité	Statut
Tableaux de bord : créer, dupliquer, définir par défaut, exporter et importer	Disponible
Grille redimensionnable en glisser-déposer avec enregistrement automatique	Disponible
KPI, tableau et l’ensemble complet des graphiques ECharts	Disponible
Configuration visuelle des widgets, sans SQL	Disponible
Réutilisation des requêtes enregistrées et génération de tableau en un clic	Disponible
Filtres globaux qui actualisent tout le tableau	Disponible
Exploration du graphique vers la liste des demandes	Disponible
Agrégation SQL et cache par utilisateur, filtrés par les droits	Disponible
Partage, modèles, thèmes clair et sombre	Disponible
Multiversion, multibase, repli côté serveur	Disponible
Export PDF, PNG et Excel	Prévu
Tâches de fond pour les rapports très lourds	Prévu
Mises à jour en direct par WebSocket	Prévu
Instantanés planifiés envoyés par courriel	Prévu
Mode kiosque / écran mural	Prévu
Générateur de rapports par IA en langage naturel	Prévu
Widgets calendrier, burndown et synthèse de Gantt	Prévu

Installation en trois étapes

Nécessite un accès shell et la possibilité de lancer des tâches rake. Sauvegardez toujours avant d'installer un plugin.

Décompresser dans le dossier plugins

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

Migrer, installer les modèles, redémarrer

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

L’activer là où vous le voulez

# 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

Modifie-t-il ou surcharge-t-il des fichiers du cœur de Redmine ?

Non. Il déclare un module de projet, des permissions, des entrées de menu et des routes via l’API documentée Redmine::Plugin.register, et ajoute ses propres contrôleurs, modèles et migrations. Le désinstaller consiste à supprimer son répertoire et à annuler ses migrations — rien n’a été touché dans le cœur qu’il faudrait remettre en place.

Faut-il Node.js ou une étape de build pour l’installer ?

Non. Un bundle frontend déjà compilé est livré dans le paquet : le plugin fonctionne dès que les migrations ont tourné et que Redmine a redémarré. Node n’est nécessaire que si vous voulez modifier le source React et le recompiler vous-même, ce que le paquet permet mais n’exige pas.

Mes requêtes enregistrées existantes fonctionnent-elles, même les compliquées ?

Oui. L’agrégation s’appuie sur le périmètre propre à la requête — exactement la relation que Redmine utilise pour afficher la liste des demandes. Les filtres qui exigent des jointures particulières, comme les champs personnalisés, les observateurs et les sous-projets, sont repris tels quels. Choisir une requête déduit aussi la source de données et un regroupement par défaut : la plupart des widgets tiennent en deux clics.

Quelqu’un peut-il voir des chiffres d’un projet auquel il n’a pas accès ?

Non. Chaque agrégation est construite sur les périmètres de visibilité de Redmine pour l’utilisateur courant avant tout regroupement, et chaque tableau de bord revérifie en plus viewable_by? à chaque requête. Une demande hors périmètre ne fait jamais partie d’un décompte : il n’y a donc aucun total à laisser fuiter.

Quelles bases de données sont prises en charge ?

MySQL, MariaDB et PostgreSQL, avec un DDL identique sur les trois. Le JSON est stocké dans de simples colonnes text, et le regroupement par date passe par un CAST(col AS DATE) portable, replié ensuite en jours, semaines, mois ou années côté Ruby — il n’y a donc pas de SQL spécifique à un éditeur, ni d’astérisque « PostgreSQL uniquement » sur une fonctionnalité.

Sur quelles versions de Redmine et de Rails tourne-t-il ?

Redmine 4, 5, 6 et 7, sur Rails 5.2 à 8.0 et Ruby 2.5 ou plus récent. Les migrations visent la base [5.2] que chacune de ces versions comprend et sont écrites de façon défensive : une mise à jour interrompue se relance simplement. Comme il n’y a aucune surcharge du cœur, rien ne peut se désynchroniser quand vous mettez Redmine à jour.

Pouvons-nous ajouter nos propres sources de données ou types de graphiques ?

Oui, depuis un plugin distinct et sans rien changer ici. Dérivez RedmineCharts::DataSource et appelez register_data_source pour une nouvelle source, ou register_widget_type pour un nouveau graphique. Les deux apparaissent immédiatement dans l’interface de configuration et héritent du filtrage, du cache et de l’exploration — c’est d’ailleurs ainsi que les deux sources intégrées sont déclarées.

Qu’est-ce qui, volontairement, n’est pas dans la version 1.0 ?

L’export PDF, PNG et Excel, les tâches de fond pour les rapports très lourds, les instantanés envoyés par courriel, la mise à jour en direct par WebSocket et un mode kiosque sont prévus mais pas encore construits — vous achetez donc ce qui est dans la boîte aujourd’hui. Tout cela est additif : rien ne vous demandera de migrer un tableau de bord déjà construit.