Redmine Reminders

Notifications

5.0 (0)·New installations

Des rappels manuels, planifiés et pilotés par des règles pour les demandes qui dorment doucement — envoyés depuis la demande, depuis une requête enregistrée ou depuis la console d’administration, par le serveur de messagerie que vous utilisez déjà.

$199 / un serveur

Plusieurs serveurs: $399

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

Types de rappel: 3
Modes de destinataire: 4
Planifications: Jour · semaine · mois
Permissions: 4, par projet
Données hors du serveur: Jamais

Relancer l’assigné maintenant

Un bouton sur la page de la demande. Il résout l’assigné — à défaut l’auteur, puis un administrateur — et le message est parti avant même que la page ne se recharge.

Relancer quelqu’un plus tard

Choisissez un destinataire, une date et une note, et le rappel attend. Si la demande est fermée avant cette date, il est marqué ignoré au lieu d’être envoyé.

Des règles sur une requête enregistrée

Attachez une règle à n’importe quelle requête : chaque jour, chaque semaine les jours choisis, ou chaque mois aux dates choisies, à une heure fixe. Les demandes ouvertes du résultat sont relancées, une fois par jour au plus.

N’envoyer que le compte

Pointez une règle sur plusieurs requêtes et envoyez les chiffres plutôt que les demandes — un pouls permanent pour les responsables qui veulent l’ordre de grandeur, pas la liste.

Personne n’est relancé deux fois

Demandes fermées, modules désactivés et comptes verrouillés sont filtrés au moment de l’envoi, et les destinataires sont dédoublonnés avant qu’un seul message ne parte.

Quatre permissions, par projet

Consulter, gérer, envoyer et voir les statistiques — attribuées par rôle, par-dessus un module de projet que vous pouvez désactiver entièrement. Chaque envoi et chaque abandon entre dans le journal.

Un clic, une date, ou une règle

Chaque rappel est stocké, distribué et journalisé de la même façon. Ce qui change, c’est qui décide du moment : vous, tout de suite ; vous, pour une date à venir ; ou une règle qui surveille une requête enregistrée à votre place.

Manuel — relancer l’assigné maintenant

Un bouton sur la page de la demande. Il résout l’assigné, se rabat sur l’auteur puis sur un administrateur si personne n’est assigné, et le message est parti avant que la page ne se recharge.

Planifié — relancer quelqu’un plus tard

Choisissez un destinataire, une date et une note, et le rappel attend. Si la demande est fermée avant cette date, il est discrètement marqué ignoré plutôt qu’envoyé : la note portait sur un travail qui n’en est plus un.

Automatique — une règle sur une requête enregistrée

Attachez une règle à n’importe quelle requête de demandes : chaque jour, chaque semaine les jours choisis, ou chaque mois aux dates choisies, à une heure fixe. Les demandes ouvertes du résultat sont relancées, et une règle se déclenche au plus une fois par jour.

La requête que vous tenez déjà, c’est la règle

Il n’y a pas de second langage de filtrage. Une règle pointe vers l’une de vos requêtes enregistrées — en retard, non assignée depuis trois jours, tickets de support dormants — de sorte que la définition de « ça dort » reste là où votre équipe l’entretient déjà. Modifiez la requête et toutes les règles qui s’appuient dessus suivent.

Il vit à trois endroits que vous utilisez déjà

Le plugin ajoute quelque chose à la page de la demande, au projet et à la console d’administration — et nulle part ailleurs. Chaque écran ci-dessous est un Redmine 6 faisant tourner Redmine Reminders 1.0.0.

Sur la demande

view_issues_show_description_bottom · onglet historique

La boîte de dialogue « Nouveau rappel » ouverte au-dessus d’une demande Redmine, avec les champs Destinataire, Date de rappel et Notes et un bouton Créer. — Relancer plus tard Destinataire, date, note — puis il attend la date.

Une demande Redmine avec l’onglet Rappels sélectionné, listant un rappel planifié avec sa date de création, son type, son auteur, son destinataire, l’état en attente, la date de rappel et la note. — Onglet Rappels Tous les rappels de la demande, avec état et note.

Dans le projet

Configuration › Rappels · menu du projet

La configuration d’un projet Redmine, section Modules dépliée, avec la case Redmine Reminders cochée à côté de Suivi des demandes et Suivi du temps passé. — Première étape Le module apparaît dans la liste des modules du projet — actif ou non, projet par projet.

L’onglet Rappels dans la configuration du projet Redmine : un formulaire avec objet, envoi du compte seul, requête personnalisée, notes, destinataire, planification, heure et champ actif, au-dessus d’un tableau de six règles existantes. — Configuration › Rappels Construisez une règle depuis une requête enregistrée, puis surveillez le tableau des règles — planification, destinataires, nombre d’exécutions, dernier résultat.

La page Mes rappels dans un projet Redmine, listant trois rappels en attente avec leur demande, leur date de rappel, leur auteur et leur note. — Mes rappels Les rappels en attente de chacun — demande, date, qui a demandé, et pourquoi.

La page de statistiques des rappels du projet, montrant les compteurs de rappels manuels et automatiques à côté d’un tableau des goulots d’étranglement par assigné listant les utilisateurs et leurs demandes ouvertes. — Statistiques des rappels Les compteurs par type, et les demandes ouvertes empilées par assigné.

Dans la console d’administration

Administration › Redmine Reminders

L’onglet Rappels de l’administration listant une règle de diffusion personnalisée avec sa date de notification, sa date de fin, sa planification quotidienne, sa liste de destinataires et son état actif. — Diffusions Des rappels rédigés par un administrateur, avec une fenêtre de dates.

Le formulaire des rappels de goulot d’étranglement, avec nom, description, contenu du courriel, dates de notification et de fin, type de notification, heure, un sélecteur « Compte verrouillé en tant que » réglé sur Assigné ou auteur, et un sélecteur d’utilisateur. — Goulots d’étranglement Surveiller les demandes ouvertes retenues par des comptes verrouillés.

Pensé pour les files que vous tenez déjà

Les rappels lisent vos requêtes enregistrées, respectent vos permissions et écrivent tout ce qu’ils font dans leur propre journal d’activité.

Ce qu’on peut demander à une règle
Aspect	Capacité	Comportement
Qui	Assigné, auteur, observateurs, ou une liste choisie	Chaque règle choisit ses destinataires. Les utilisateurs inactifs et ceux sans adresse de messagerie sont écartés avant tout envoi.
Quand	Chaque jour, semaine ou mois à HH:MM	Les règles hebdomadaires choisissent des jours de semaine, les mensuelles des dates, et une date de début et de fin bornent l’ensemble.
Synthèse	N’envoyer que le compte	Pointez une règle sur plusieurs requêtes et envoyez les chiffres plutôt que les demandes — un pouls permanent pour les responsables.
Garde-fou	Une demande fermée n’est jamais relancée	Demandes fermées, modules de projet désactivés et comptes verrouillés sont filtrés au moment de l’envoi, pas au moment de la planification.
Preuve	Un journal d’activité complet	Créé, envoyé, ignoré, exécution de règle démarrée, exécution de règle terminée — chacun avec l’objet et le corps exacts qui sont partis.
Accès	Quatre permissions, par projet	Consulter, gérer, envoyer et voir les statistiques — attribuées par rôle, par-dessus un module de projet que vous pouvez désactiver entièrement.

Un tic de cron entre, un courriel sort

Quatre étapes, toutes à l’intérieur de votre Redmine. Rien ne quitte le serveur, hormis le courrier que votre instance envoie déjà.

Étape	Ce qui se passe
1. Le cron tique	Une ligne de crontab lance rake redmine_reminders:queue, qui met un travail en file d’attente. Sans worker en marche, la tâche synchrone :run fait le même travail sur place.
2. Les règles s’interrogent	Chaque règle active se demande si elle est due : dans sa fenêtre de dates, correspondant au jour ou à la date d’aujourd’hui, passée son heure planifiée, et pas déjà exécutée aujourd’hui.
3. Les destinataires se résolvent	La requête s’exécute, les demandes fermées tombent, et les destinataires deviennent des utilisateurs réels, actifs et joignables. Les doublons fusionnent : personne ne reçoit deux fois la même relance.
4. Envoyer, puis journaliser	La distribution passe par le mailer de Redmine, dont elle hérite ainsi la configuration SMTP et les en-têtes de courriel des demandes. Chaque envoi — et chaque abandon — est écrit dans le journal d’activité des rappels avec son objet et son corps.

Ce qui arrive dans la boîte de réception

Un objet qui porte le projet et la demande — [Support — #4821] Redmine Reminder: SSO login fails on Safari — au-dessus d’un corps qui renvoie directement à la demande et cite la note écrite par la personne qui a posé le rappel. C’est le mailer de votre instance, votre configuration SMTP et votre adresse d’expédition ; le plugin n’ajoute aucun chemin de distribution.

Personne n’est relancé deux fois

Un plugin de rappels se justifie par ce qu’il refuse d’envoyer. Quatre contrôles se tiennent entre une règle due et une boîte de réception.

Filtré à l’envoi, pas à la planification

Demandes fermées, projets dont le module a été coupé et comptes verrouillés sont revérifiés au moment précis où le courriel va partir — un ticket résolu il y a une heure est déjà hors du lot.

Uniquement des utilisateurs réels et joignables

Les destinataires sont développés en comptes réels, puis les utilisateurs inactifs et ceux sans adresse sont écartés. Un groupe d’observateurs dont la moitié a quitté l’entreprise atteint l’autre moitié.

Au plus une fois par jour, par règle

Une règle déjà exécutée aujourd’hui ne repartira pas, quoi que fasse le cron. Au sein d’une exécution, les destinataires en double fusionnent : une personne présente sur trois des demandes trouvées reçoit un seul message.

Les abandons aussi sont consignés

Un rappel planifié pour une demande fermée entre-temps est journalisé comme ignoré, avec sa raison. Le journal répond à « pourquoi personne n’a été relancé ? » aussi bien qu’à « qui a été relancé ? ».

Diffusions, goulots d’étranglement et preuves

La console d’administration ajoute les trois choses qui n’ont de sens qu’à l’échelle de tous les projets à la fois.

Diffuser à tous ceux que ça concerne

Rédigez un objet et un corps, choisissez les destinataires et une fenêtre de dates : le planificateur qui exécute les règles se charge de la distribution. Pas d’outil d’emailing séparé, et le même journal d’activité ensuite.

Trouver les comptes qui bloquent

Une règle surveille chaque demande ouverte assignée à un compte verrouillé, ou créée par lui, et envoie la liste à qui doit réassigner le travail. Les départs cessent d’être un arriéré silencieux.

Des statistiques qui nomment

Comptes manuels et automatiques par personne, sur la période de votre choix, avec le détail de l’objet et du corps exacts reçus par chaque utilisateur. Utile quand quelqu’un affirme n’avoir jamais été prévenu.

Les quatre permissions, attribuables par rôle
Permission	Ce qu’elle autorise
Consulter les rappels	Voir les rappels et les règles attachés aux demandes d’un projet
Gérer les rappels	Créer, modifier, suspendre et supprimer les règles posées sur les requêtes enregistrées d’un projet
Envoyer des rappels	Utiliser le bouton manuel sur une demande et en planifier un pour plus tard
Voir les statistiques	Ouvrir les comptes par personne et le journal d’activité qui les soutient

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
# the package arrives by email, or from your download link
unzip redmine_reminders-1.0.0.zip -d plugins/
bundle install

Migrer et redémarrer

RAILS_ENV=production bundle exec rake redmine:plugins:migrate NAME=redmine_reminders
touch tmp/restart.txt   # or systemctl restart redmine

Ajouter la ligne de crontab

# every minute: enqueue due rules and scheduled reminders
* * * * * cd /path/to/redmine && RAILS_ENV=production \
  bundle exec rake redmine_reminders:queue >> log/redmine_reminders_cron.log 2>&1

# no ActiveJob worker? use the synchronous task instead
# bundle exec rake redmine_reminders:run

Faut-il un worker en tâche de fond ?

Non. L’entrée de cron lance redmine_reminders:queue, qui met un ActiveJob en file et rend la main immédiatement — la bonne forme si vous faites déjà tourner un worker. Sinon, pointez la même ligne vers redmine_reminders:run et le travail se fait de façon synchrone dans ce processus. Les deux tâches peuvent tourner chaque minute sans risque.

Que se passe-t-il si une demande est fermée avant son rappel planifié ?

Rien n’est envoyé. Le rappel est marqué ignoré et écrit au journal d’activité avec sa raison, de sorte que la trace de l’intention subsiste sans que personne ne soit relancé sur un travail terminé. Le même contrôle vaut pour les rappels pilotés par une règle : les demandes fermées sont retirées du résultat au moment de l’envoi.

Qui reçoit réellement un rappel ?

Chaque règle choisit l’un des quatre modes de destinataire : l’assigné, l’auteur, les observateurs, ou une liste d’utilisateurs que vous désignez. Les rappels manuels résolvent d’abord l’assigné, puis se rabattent sur l’auteur et enfin sur un administrateur. Dans tous les cas, les utilisateurs inactifs et ceux sans adresse sont écartés avant l’envoi, et les destinataires en double fusionnent en un seul message.

Une règle peut-elle couvrir plusieurs requêtes et n’envoyer que les chiffres ?

Oui. Une règle en mode « compte seul » peut viser plusieurs requêtes enregistrées et envoie les totaux plutôt que les demandes — douze en retard, trois non assignées, une bloquée — ce qui est en général exactement ce qu’un responsable veut trouver dans sa boîte à neuf heures.

Est-ce que quelque chose passe par un service externe ?

Non. Le courrier est remis au mailer de Redmine et utilise donc la configuration SMTP et l’adresse d’expédition que votre instance possède déjà. Aucun service externe, aucune clé d’API à obtenir, aucune télémétrie : le plugin ajoute des tables et des tâches rake, pas un chemin de distribution.

Comment éviter les avalanches de courriels ?

De trois façons. Une règle se déclenche au plus une fois par jour, quelle que soit la fréquence du cron ; les destinataires sont dédoublonnés au sein d’une exécution, si bien qu’une personne concernée par trente demandes reçoit un message ; et les filtres appliqués à l’envoi retirent les demandes fermées, les modules désactivés et les comptes verrouillés avant toute adresse.

Qui a le droit de créer des règles ?

Qui vous voulez. Quatre permissions — consulter, gérer, envoyer et voir les statistiques — sont attribuées par rôle et ne s’appliquent que là où le module Rappels a été activé pour le projet. Un projet qui n’active jamais le module n’a ni rappels, ni entrée de menu, ni règles.

Quelles versions de Redmine sont prises en charge, et qu’ajoute-t-il en base ?

Redmine 4.0 et plus récent, via l’API de plugins standard — aucun fichier du cœur n’est modifié. Il ajoute trois tables à lui par des migrations ordinaires ; désinstaller consiste à retirer le répertoire du plugin et à annuler ces migrations.