Voir le texte original de ce document.

Koha dispose d'un mécanisme d'envoi de messages aux usagers de la bibliothèque ainsi qu'à son personnel. Ce système utilise des modèles de message et envoie des courriels. LibLime propose d'améliorer la gestion des messages dans Koha en y ajoutant les fonctionnalités suivantes :

• À l'OPAC, dans l'onglet Préférences de ses informations personnelles, un adhérent pourra contrôler quels types de message il recevra.
• Amélioration des modèles de lettre. Ajout de sections en-tête, pied de page et de sections répétables.
• Envoi des messages par SMS et unification avec les autres méthodes d'acheminement.
• Envoi des messages via une interface avec un système de téléphonie.
• Fils RSS pour recevoir ses messages.
• Fil centralisé des messages de façon à séparer la génération des messages de leur envoi.
• Mécanisme d'injection dans la fil de messages issus d'une autre source.
• Unification du code en un unique groupe de modules qui se chargent des fonctions d'envoi de courriels et des autres types de messages.

En plus, plusieurs types de messages de circulation seront ajoutés :

• avis d'événement ou de classe,
• envoi d'un avis au moment même où un exemplaire passe au statut En retard,
• envoi d'un avis avant la date de retour prévu.

Auteur initial : Daniel Sweeney (daniel.sweeney at liblime dot com)

Les bibliothèques veulent pouvoir envoyer à partir de Koha des avis et des alertes à leurs usagers. De leur côté, les emprunteurs veulent contrôler la façon dont ils reçoivent ces messages et dans certains cas s'ils convient même de les recevoir.

Ce document technique détaille ce qu'il convient de faire afin d'améliorer le système de notification de Koha.

Par défaut, Koha fournit les notifications suivantes :

1. avis de retard,
2. réclamation d'acquisition,
3. fiche de circulation de périodique,
4. nouvel enregistrement d'un emprunteur.

Ces notifications sont installées au démarrage du système. Les administrateurs de Koha peuvent ajouter d'avantage de notifications dans la section Outils de l'application. Les avis sont définis au moyen d'un système de modèle de page capable d'interpoler des valeurs uniques dans le texte de l'avis. Ces valeurs sont en général directement extraites de la base de données, la substitution du texte s'opérant à partir d'une colonne d'une table. Il n'y aucun moyen d'inclure un sous-modèle où de répéter une section du modèle. Ces modèles comprennent également un nom et un sujet du message. Ils sont stockés dans la table letter.

Chaque avis est associé à un module : Catalogue, Périodique (fiches de circulation), Réclamations des acquisitions, Réclamations des périodiques, Adhérents. Cette association est enregistrée dans le champ module de la table letter. Cette colonne ne fait référence à rien dans la base de donnes.

Dans certains cas, les bibliothèques peuvent remplacer des avis ou en ajouter de nouveaux. Ainsi dans la zone Déclencheurs de notification, on ajoute au système de traitement des réclamations de nouveaux avis de retard ou bien on en modifie certains. Le module Koha associé à un avis indique s'il faut inclure cet avis à une zone fonctionnelle particulière.

La fiche d'information d'un emprunteur contient plusieurs zones d'adresse. Il y a des adresses et des noms de contact primaires et alternatifs. Il n'y pas de moyen désactiver des adresses ou de spécifier pour chacune une période de validité.

Il sera ajouté à Koha :

1. un avis Exemplaire emprunté ;
2. un avis Exemplaire rendu ;
3. un avis de courtoisie ;
4. un avis Cours sur le point de commencer. Il y aura une interface avec un système séparé de gestion des horaires des cours de la bibliothèque. Cette interface sera généralisable pour permettre d'injecter dans Koha des messages issus de tout système tierce-partie ;
5. un avis Juste en retard (distinct de l'avis ordinaire de retard).

La plupart des nouvelles notifications seront envoyées sous forme électronique, courriel ou SMS, plutôt que par voie postale. En particulier, le nouvel avis de retard sera une notification immédiate tandis que les avis traditionnels de retard pourront continuer à être envoyés par la poste et avoir ainsi un caractère plus officiel.

1. De multiples mécanismes d'acheminement pourront être définis et configurés. Au minimum, les mécanismes suivants seront disponibles :
   1. courrier postal ;
   2. courriel ;
   3. SMS, via une passerelle de courriel ou via une passerelle SMS dédiée ;
   4. flux de syndication RSS ou Atom ;
   5. système de circulation par téléphone. Ce système pourra lire des informations préparées en dehors de la base de données Koha ;
2. Les mécanismes d'acheminement auront différents éléments de configuration. La plupart seront associés à une adresse spécifique de la fiche de l'emprunteur. Par exemple, le mécanisme d'envoi par SMS utilisera le champ Mobile de l'emprunteur et si cette colonne est vide, le mode d'envoi par SMS sera désactivé.
3. L'acheminement par voie postale est utilisé par défaut si les autres adresses ne sont pas renseignées.
4. Les mécanismes d'acheminement seront configurables par succursale dans une installation de Koha à plusieurs succursales.

1. Chaque notification aura des options spécifiques. Par exemple, les administrateurs pourront configurer les notifications Exemplaire emprunté et Exemplaire rendu pour qu'elles soient envoyées à certaines combinaisons de catagories d'emprunteur et de types d'exemplaire.
2. Comme auparavant, la colonne Module de la table letter déterminera l'usage des notifications. Ce qui impliquera que ce champ ne référencera pas un module de Koha mais plutôt un type d'avis générique.
3. Pour chaque notification, on pourra choisir un modèle différent par mécanisme d'acheminement. D'où il découle qu'il y aura de multiples modèles dans la table letters, un par mécanisme d'acheminement. Il est possible que certains mécanisme d'acheminement utilisent des modèles totalement différents de ceux utilisés pour les lettres : des sorties non-textuelles par exemple.
4. Le groupe des notifications disponibles sera stockée dans la table authorized_values. Ces valeurs autorisées détermineront l'intervalle des valeurs utilisables dans la colonne module de la table letter. Une autre approche consisterait à créer une nouvelle table des types de notification, mais il semble bien que l'usage dans Koha soit d'utiliser la table authorized_values à cet effet.

1. Des notifications seront configurables dans l'OPAC par l'emprunteur lui-même ; d'autres ne seront configurables que par les administrateurs. Ce comportement sera paramétré par notification pour chaque catégorie d'emprunteur.
2. Certaines notifications seront désactivables par les emprunteurs. Ce sera paramétrable par les administrateurs pour chaque catégorie d'emprunteur.
3. Un nouvel onglet sera ajouté à la fiche de l'emprunteur dans l'OPAC qui contiendra la configuration des notifications. L'emprunteur choisira :
   1. pour chaque type de message défini, s'il souhaite le recevoir via SMS, courriel, RSS, ou une combinaison de ces options ;
   2. pour certains types de message, s'il souhaite recevoir une version condensée du message ;
   3. le numéro de téléphone pour les messages SMS.
4. Par défaut, les messages courriel et RSS arriveront dans une forme condensée. Les messages SMS paramétrés pour être envoyés sous forme condensée indiqueront uniquement le nombre d'exemplaires attendus dans les n jours et ne contiendront pas leurs titres. Les emprunteurs auront le droit de donner un numéro de téléphone mobile utilisé pour les SMS qui pourra être différent des numéros de leur fiche d'emprunteur de la bibliothèque.

1. Les administrateurs pourront décider s'il est possible d'envoyer les notifications sous forme condensée par notification et par mécanisme d'acheminement.
2. Le mode condensé peut ne pas être applicable à certaines combinaisons de notification et de mécanisme d'acheminement. Il sera possible de spécifier que certains mécanismes d'acheminement ne supportent pas le mode condensé.

1. Si une notification donnée est configurable par les emprunteurs, ils seront autorisés à :
   1. sélectionner les mécanismes d'acheminement qu'ils souhaitent utiliser, éventuellement plus d'un mécanisme. L'emprunteur doit avoir l'adresse idoine pour faire cette sélection ;
   2. désactiver la notification si le système l'autorise pour cette notification ;
   3. choisir de recevoir la notification sous forme condensée. Dans ce mode, plusieurs notifications seront regroupées dans un seul message.
2. Le personnel gérant la circulation dans Koha pourra également configurer pour les emprunteurs les mécanismes d'acheminement. Cela se fera dans un nouvel onglet Messagerie.

Ce qui suit décrit les fonctionnalités minimales attendues d'un système de gestion des modèles de notification. Si une meilleure solution existe déjà dans la communauté Perl, elle sera utilisée. Les fonctions de base comprennent la possibilité de gérer des données répétables pour les messages condensés : par exemple, être capable de remplir les sections statiques d'en-tête et de pied-de-page avec plusieurs exemplaires pour les avis de retard.

1. Afin de remplir le message, chaque modèle de notification aura accès à un ensemble de champs de la base de données qui sera fonction du type de notification.
2. Chaque modèle de notification aura trois sections : un en-tête, un corps et un pied-de-page.
3. L'en-tête sera toujours en début du message.
4. Le corps sera placé après l'en-têtre.
5. Si un modèle supporte la forme condensée, le corps du message sera répété pour chaque entrée. Par exemple, pour les avis de retard, le corps sera répété pour chaque exemplaire en retard.
6. Le pied-de-page sera placé après le corps.
7. Les sections en-tête et pied-de-page pourront être réutilisées par plus d'une notification, y compris en mode non-condensé.

1. Si les flux de syndication sont disponibles comme mécanisme d'acheminement, et si les notifications sont configurées pour les supporter, alors les flux de syndication seront générés par modèle de notification comme ceux qui produisent des avis textuels pour les courriels. Les modèles génèreront des entrées dans les flux au format XML.
2. Un processus séparé prendra chaque exemplaire ou entrée et le placera dans un flux de syndication.
3. Les flux seront en RSS 2.0.
4. La forme condensée n'est pas applicable aux flux de syndication. Le mécanisme qui génère le flux prend soin de regrouper les exemplaires individuels dans le flux. Il y a des dépendances à l'intérieur d'un flux RSS entre différents élément du flux XML.
5. Les exemplaires seront placés dans le flux en utilisant la date à laquelle le système les a générés. Il n'y aura pas de tri a posteriori sur des dates internes telles que la date de retour d'un prêt. Pour chaque entrée, il y aura un champ contenant la date de retour. (Cela correspond à l'usage, et à ce qui est fait par exemple par Google Calendar.)
6. Les exemplaires seront retirés du flux après une durée donnée qui sera configurable pour le mécanisme d'acheminement. Par défaut, cette durée sera de trente jours.
7. Les flux de syndication de niveau emprunteur requerront une autorisation par authentification http. Le nom de l'emprunteur et son mot de passe seront ceux-là même utilisés dans l'OPAC.
8. Il doit être possible de configurer Koha afin de ne rendre accessible les flux que par https (protection pas SSL). Certaines bibliothèques n'ayant pas ce type de préoccupation, ou bien n'ayant pas de certificat SSL, la connection https ne sera pas requise.
9. Chaque notification aura son propre flux de sydication.

1. Certaines bibliothèques exigent que tous les messages sortants soient archivés.
2. LibLime propose de créer une file des messages qui sera utilisée pour :
   1. mettre en attente les messages préparés (par exemple par une tâche de gestion des exemplaires en retard) ;
   2. stocker les messages pour les archives de la bibliothèque ;
   3. stocker les messages pour les utiliser dans les flux RSS ;
   4. permettre l'écriture d'un programme générique de traitement et d'envoi des messages en attente ;
3. Si une file explicite de messages est utilisée, elle sera visible par la bibliothèque mais pas modifiable.
4. Quand les transaction des emprunteurs sont anonymisées, les entrées correspondantes de la file des messages seront également anonymisées.

1. Les cinq champs de contact des emprunteurs deviendront répétables : Téléphone (maison), Téléphone (travail), Courriel (maison), Courriel (travail) et Fax.
2. Le personnel pourra ajouter de nouvelles valeurs à ces champs ou bien supprimer d'anciennes valeurs.
3. Les emprunteurs pourront ajouter de nouvelles valeurs à ces champs mais ne pourront pas supprimer des valeurs existantes.
4. Les emprunteurs ne pourront pas ajouter des adresses du même type en double, mais pourront ajouter des adresse en double de types différents, comme par exemple le même numéro pour Téléphone (maison) et Fax.
5. Quand les emprunteurs auront ajouté de nouvelles valeurs aux champs de contact, ces valeurs seront protégées et ne pourront être écrasées par l'outil de chargement par lot des emprunteurs.
6. Le chargeur des emprunteurs pourra ajouter plusieurs valeurs dans les cinq champs de contact en plaçant plus d'une valeur séparée par une virgule dans le champ approprié du fichier CSV d'entrée.
7. Les emprunteurs pourront choisir toute adresse d'un type donné pour le mécanisme d'acheminement correspondant.
8. Les administrateurs décideront par type d'emprunteur si les emprunteurs sont autorisés à ajouter de nouvelles adresses via l'OPAC.

1. Le personnel pourra désactiver et réactiver toute adresse d'un emprunteur, à l'exception de l'adresse postale.
2. Quand une adresse sera désactivée, elle ne sera pas utilisable pour envoyer des messages et toute notification précédemment définie utilisant cette adresse ne sera plus envoyée.
3. Concernant les adresses répétables, elles seront désactivables individuellement, sans que toutes les adresses du même type soient désactivées.
4. Si une adresse particulière est désactivée et si le chargeur des emprunteurs la remplace, elle restera désactivée. Dit autrement, le chargeur des emprunteurs ne modifie pas le statut d'activation d'une adresse.
5. L'emprunteur verra dans l'OPAC ses adresses qui sont désactivées mais il ne pourra pas les réactiver.
6. Koha empêchera un emprunteur d'entrer une nouvelle adresse ayant même valeur qu'une adresse qui a été désactivée.
7. Dans le module Outils, les administrateurs pourront charger un fichier des adresses d'un type donné à désactiver ou à réactiver. Ce sera un simple fichier texte contenant une adresse par ligne.
   1. Pour chaque ligne, toutes les adresses correspondantes du type spécifié seront désactivées ou réactivées.
   2. Si une adresse se trouve dans le fichier texte mais pas dans la base de données, un avertissement sera enregistré que l'administrateur pourra consulter après que le traitement sera achevé.
   3. Si une adresse se trouve dans le fichier texte et correspond à plus d'un emprunteur, un avertissement sera enregistré que l'administrateur pourra consulter après achèvement du traitement. Les adresses trouvées seront toutefois bien désactivées ou réactivées.
8. Certains mécanismes d'acheminement permettent de savoir immédiatement si une adresse est invalide. Aussi ces mécanismes pourront-ils eux-mêmes désactiver des adresses.
9. D'autres mécanismes d'acheminement ne peuvent pas toujours déterminer si une adresse est invalide. Ce sont les administrateurs qui devront collecter les adresses invalides à partir des retours du mécanisme d'acheminement, ajouter ces adresses à un fichier texte puis lancer le traitement de désactivation à partir de ce fichier.

1. La zone Mécanismes d'acheminement de l'Admnistration sera contrôlée par un droit simple de type oui/non. Les administrateurs n'ayant ce droit ne pourront pas entrer dans cette zone. Ceci dit, les mécanismes d'acheminement étant spécifiques à chaque succursale, l'affiliation d'un administrateur à une succursale déterminera également son droit de notificiation des mécanismes pour des succursales.
2. Le personnel gérant le prêt pourra modifier les mécanismes d'acheminement utilisés par les emprunteurs s'il a le droit de modifier les emprunteurs : il n'y aura pas de permission spécifique pour le mécanisme d'acheminement.
3. Les administrateurs décideront par catégorie d'emprunteur si les emprunteurs seront autorisés à modifier leurs adresses dans l'OPAC.

1. Ce qui précède ne traite pas des avis qui ne concernent pas les emprunteurs comme les réclamations des acquisitions.
2. Les passerelles téléphoniques pourraient devenir d'autres mécanismes d'acheminement.
3. Il y a des difficultés de mise à cache des flux de syndication. Le flux lui-même ne sait pas si un emprunteur l'a utilisé ou non, ou encore si un emprunt a été rendu.
4. Il serait peut-être souhaitable d'avoir un support Atom pour les flux de syndication. Pour le moment, il est prévu que nous travaillerons sur des flux RSS que nous connaissons mieux.
5. Il serait envisageable de mettre en oeuvre un système de reprise sur erreur qui, par exemple, si un SMS ne peut pas être envoyé, essaierait d'envoyer la notification par courriel. Cela présente certaines difficultés. On sait difficilement si un message a été envoyé ou non et les administrateurs auront à gérer une hiérarchie de mécanismes d'acheminement.