Koha 20.11

Avec la version 20.11, Koha accélère encore le rythme. Cette version poursuit le profond travail de refonte du code qui s'aligne sur des standards élevés d'ingénierie de développement informatique. Cela apporte à Koha davantage de stabilité et de maintenabilité, et ouvre de vastes perspectives d'évolution. Mais ce n'est pas tout. Ce renouveau du code se voit dès à présent. De nouvelles fonctionnalités remarquables font leur apparition. Koha est toujours plus paramétrable et plus simplement paramétrable. Les bibliothécaires interagissent avec leur SIGB préféré au moyen d'une interface homme-machine plus riche et plus souple. L'intégration de Koha au système d'information des établissements est simplifiée et approfondie grâce à la couverture fonctionnelle élargie des services web et à l'enrichissement des mécanismes d'échanges des plugins avec Koha.

Nouvelles fonctionnalités

Traitements longs

Certains traitements dans Koha prennent beaucoup de temps à s'exécuter. Ce sont par exemple, l'indexation ou bien les modifications par lot des notices bibliographiques ou des autorités. L'architecture de Koha rend difficile la bonne exécution de ces traitements longs. Cela vient de ce que certains scripts sont des scripts CGI, tandis que d'autres sont exécutés avec Plack. Une nouvelle brique logicielle, RabitMQ, a été ajoutée à Koha afin de résoudre cette limitation. RabitMQ est un agent de message. C'est un logiciel qui permet d'échanger des messages entre des émetteurs et des récepteurs de messages. L'utilisation d'un agent de message par Koha permet de découpler les traitements longs des pages web qui les lancent. Ce découplage a d'ores et déjà été réalisé pour les modifications par lot de notices biblio et d'autorité. Par la suite, l'agent de message pourra être utilisé par toutes sortes d'autres traitements. On peut même imaginer, demain, confier l'exécution de ces traitements à des logiciels tiers.

Nombre de prêts par groupe de type de documents

Il n'était pas possible jusqu'à présent de limiter le nombre de prêts pour un groupe de types de document. On ne pouvait pas dire par exemple : pour les CD/DVD/VHS, on ne peut emprunter que quatre exemplaires, que ce soit 3 CD et 1 DVD, ou 2 CD et 2 DVD, etc. On devait fixer une limite à 4 pour chaque type de document et un lecteur ayant déjà emprunté 4 DVD ne pouvait pas être bloqué quand il voulait emprunter un CD en plus.

Une nouvelle fonctionnalité a été ajouté qui permet de fixer une limite max d'emprunts pour un regroupement de types de document. Dans la définition d'un type de document, un nouveau champ a été ajouté : code parent. Voir Administration > Types de document. Ce champ permet de renvoyer un type de document vers un autre, qu'on appelle le parent. L'emprunt d'un document vérifie maintenant que la limite du type de document lui-même n'est pas dépassée et que la limite du type de document parent n'est pas dépassée non plus, le type parent comptabilisant tous les prêts des types enfants.

Ce qui pour l'exemple précédent, pourrait donner :

• Un (nouveau) type MEDIA limité à 4 prêts
• Un type CD limité à 4
• Un type DVD limité à 4
• Un type VHS limité à 2

Ainsi si un lecteur commence par emprunter deux VHS, il sera bloqué s'il essaie d'emprunter un troisième VHS. Il pourra toutefois emprunter encore deux DVD. Mais s'il essaie d'emprunter un CD, il sera bloqué. Ce n'est pas la limitation CD qui sera appliquée (c'est son premier CD emprunté) mais la limitation du type MEDIA qui comptabilise déjà quatre emprunts (2 VHS + 2 DVD).

Motif pour lequel une réservation est annulée

Sur le modèle des suggestions d'achat qu'on peut refuser en indiquant un motif et en envoyant une notification au lecteur, on peut désormais, quand on annule une réservation, spécifier une raison.

• CANCELLATION_REASON est la liste des valeurs autorisées dans laquelle on choisit la raison de l'annulation de la réservation.

• HOLD_CANCELLATION est la notification qui sera envoyée au lecteur quand une raison est spécifiée.

• cancel_expired_holds.pl, le script d'annulation des réservations expirées dispose d'un paramètre supplémentaire --reason. La raison fournie au script, provenant de la liste de valeurs autorisées CANCELLATION_REASON, sera disponible dans la notification qui sera envoyée au lecteur.

Numérotation des paiements et des reçus

Dans l'onglet Comptabilité d'un adhérent, on voit toutes les transactions comptables réalisées entre la bibliothèque et l'adhérent. Les paiements reçus par la bibliothèque ne sont pas identifiés par un numéro. Une nouvelle fonctionnalité ajoute la possibilité de numéroter automatiquement certains types de transactions de paiement.

Vous activez cette fonctionnalité de la façon suivante :

• La préférence système AutoCreditNumber active la fonctionnalité. Quatre choix sont proposés :

  • Ne pas générer automatiquement un numéro de crédit
  • Numéro de la forme <année>-0001
  • Numéro de la forme yyyymm001
  • Numéro de la forme 1, 2, 3

• Pour un type de crédit, au moins, activez la numérotation automatique. Aller en Administration > Type de crédit. Sur un type de crédit, cochez Activer le n° de crédit.

• Allez en Administration > Paramétrage des tables. Pour la table account-fines de la section Adhérents, montrez la colonne credit_number qui est cachée par défaut.

• Allez en Outils > Notification et modifiez ACCOUNT_CREDIT. Ajoutez sur le reçu : [% account.credit_number %]

Avec ce paramétrage, quand vous encaisserez le paiement d'un lecteur, en choisissant un type de crédit avec numérotation automatique :

• Un numéro de crédit sera automatiquement ajouté séquentiellement à la transaction.
• Le numéro de crédit sera affiché dans une nouvelle colonne.
• Le reçu imprimé comportera le numéro de crédit.

PEB

Les fonctionnalités de Prêt-entre-Bibliothèques (PEB) de Koha ont été étendues. En relation avec les PEB, des notifications sont émises, déclenchées soit par le personnel soit par des événements.

• Par le personnel pour le lecteur :
  • PEB prêt à être retiré
  • Demande non disponible
  • Demande envoyée à un partenaire
• Pour le personnel :
  • Demande modifiée par le lecteur
  • Demande annulée par le lecteur

En Administration > Tous les sites, un nouveau champ a été ajouté à la fiche des bibliothèques. Le champ Courriel ILL sera utilisé pour envoyer les notifications adressées au personnel. En son absence, la préférence ILLDefaultStaffEmail est utilisée. La préférence ILLSendStaffNotices spécifie par ailleurs les événements qui déclencheront l'envoi de notifications au personnel.

Pour les lecteurs, les préférences de notification ont été étendues : PEB arrivé, PEB non disponible.

Quatre nouvelles notifications : ILL_REQUEST_CANCEL, ILL_REQUEST_MODIFIED, ILL_PICKUP_READY, ILL_PARTNER_REQ, ILL_REQUEST_UNAVAIL.

Anonymisation

Une nouvelle procédure d'anonymisation des données des lecteurs a été ajoutée à Koha. Le but de l'anonymisation est de conserver autant de données possibles relatives aux transactions dans Koha tout en rendant impossible/difficile l'identification des lecteurs. Il y a déjà dans Koha plusieurs façons d'anonymiser les données des lecteurs mais qui présentent l'inconvénient de perdre des données nécessaires à la préparation de rapports statistiques.

La nouvelle procédure d'anonymisation introduit deux nouvelles tables :

• pseudonymized_transactions — contient les transactions et les informations des lecteurs, les prêts, retours, renouvellements, prêts sur place.
• pseudonymized_borrower_attributesfor — contient les données des lecteurs qui ont été spécifiquement choisies par la bibliothèque afin d'être conservées lors de l'anonymisation.

Trois préférences système contrôlent le fonctionnement de l'anonymisation :

• Pseudonymization — Active/désactive l'anonymisation.
• PseudonymizationPatronFields — Liste les données des lecteurs à envoyer dans les tables d'anonymisation.
• PseudonymizationTransactionFields — Listes les catégories de transactions à envoyer dans les tables.

Par ailleurs, le script de purge cleanup_database.pl a été amélioré pour permettre de vider les nouvelles tables nécessaires à l'anonymisation.

Serveurs SMTP multiples

L'envoi des courriels par Koha fonctionnait jusqu'à présent de façon monolithique et extérieure à Koha. Les messages étaient confiés au serveur SMTP du serveur Koha. L'administrateur système du serveur Koha pouvait ensuite paramétrer le serveur SMTP afin d'affiner les choses : sécuriser, confier les messages à un serveur intermédiaire, etc. Des installations avancées pouvaient comporter, sur un même serveur, plusieurs instances de Koha et des instances multi-bibliothèques. De là, une configuration SMTP qui pouvaient devenir très complexes.

La gestion de l'envoi des courriels a été complètement refondu dans cette version de Koha. Une configuration fine de l'envoi des emails est désormais paramétrable directement depuis l'interface d'administration de Koha. Les nouveaux éléments de configuration et fonctionnels sont les suivants :

SMTP par défaut — Au moment de l'installation de Koha, un serveur SMTP par défaut est défini dans le fichier de configuration koha-conf.xml.

<smtp_server>
  <host>localhost</host>
  <port>25</port>
  <timeout>120</timeout>
  <ssl_mode>disabled</ssl_mode>
  <user_name></user_name>
  <password></password>
  <debug>0</debug>
</smtp_server>

Serveurs SMTP multiples — Dans l'administration de Koha, une nouvelle page permet de définir autant de serveurs SMTP que nécessaire. Une nouvelle permission manage_smtp_servers doit être attribuée pour donner accès à : Administration > Serveurs SMTP. Les serveurs sont enregistrés dans deux nouvelles tables : smtp_servers et library_smtp_servers.

SMTP par bibliothèque — Dans le paramétrage d'une bibliothèque (Administration > Tous les sites), un nouveau champ permet de choisir le serveur SMTP utilisé pour l'envoi des courriels par cette bibliothèque. Cela peut être le serveur SMTP par défaut ou un des serveurs paramétrés en Administration.

Téléchargement dans le réservoir avec profil

La page de téléchargement de notices bibliographiques ou d'autorités dans le réservoir est riche de multiples options qu'il est facile d'oublier d'un chargement à l'autre. Une nouvelle fonctionnalité permet de créer des profils qui enregistrent l'ensemble des paramètres de chargement. On peut ainsi définir un certain nombre de profils qu'on peut utiliser pour les différentes catégories de notices que l'on charge régulièrement dans son système.

• Création d'un profil — Dans la page de téléchargement dans le réservoir, on choisit toutes les options nécessaires. Une fois que c'est fait, avant de cliquer sur le bouton Télécharger dans le réservoir, à droite de ce bouton, on saisit un nom de profil puis on clique sur Enregistrer profil. Le nouveau profil sera disponible ultérieurement. Si on saisit le nom d'un profil existant, il sera remplacé après confirmation.

• Utilisation d'un profil — Dans la page de téléchargement dans le réservoir, plutôt que de remplir manuellement le formulaire, on choisit un profil dans la nouvelle section Profil de chargement. Les options enregistrées dans le profil sont utilisées pour remplir les options de la page.

Améliorations

Acquisitions

• Colonne budget ajoutée aux commandes en retard — En Acquisitions > Commandes en retard, le tableau des commandes affiche une colonne supplémentaire : Poste budgétaire. La colonne est visible par défaut. Elle peut être désactivée en Administration > Paramètres des tables > Acquisitions > late_order : colonne budget.

• Prix dans l'onglet Acquisition de le page Détail — Sur la page de détail d'une notice biblio, les infos relatives aux acquisitions sont affichées dans l'onglet Acquisition. Le prix estimé d'achat est désormais affiché. Son affichage peut être désactivé en Administration > Paramètres des tables > Catalogue > Acquisitions > details-table, colonne price.

• Infos du panier dans les notifications — Dans les notifications utilisées lors des commandes (comme AQORDERS), il est désormais possible d'inclure des informations relatives au panier de commande. Par exemple, pour afficher le nom du panier : [% aqbasket.basketname %]

• Suggestions d'achat — Une nouvelle préférence SuggestionsUnwantedFields permet de masquer certains champs de la page de suggestions d'achat de l'OPAC. Cette nouvelle préférence rend obsolète la préférence AllowPurchaseSuggestionBranchChoice qui contrôlait uniquement l'affichage du champ Bibliothèque.

• Import manuel des factures Edifact — Jusqu'à présent, les factures Edifact étaient téléchargées automatiquement dans Koha au moyen d'un script et immédiatement importées dans le module Acquisitions. Une nouvelle préférence EdifactInvoiceImport permet de rendre manuelle l'opération d'import des factures. Quand la préférence est activée, en Administration > Messages Edifacts, les factures affichent un bouton Importer. En cliquant sur ce bouton, il disparaît et la facture est marquée comme reçue.

• Permissions supplémentaires — Quatre permissions ont été ajoutées afin d'affiner l'attribution de droits sur les éléments du processus d'acquisition :

  • reopen_closed_invoices pour rouvrir et fermer les factures
  • edit_invoices pour modifier les factures
  • delete_invoices pour supprimer les factures
  • merge_invoices pour fusionner les factures
  • delete_baskets pour supprimer les paniers

• Compteur des suggestions d'achat — Un compteur des suggestions d'achat est affiché sur la page d'accueil de l'interface professionnelle. Jusqu'à présent, c'est le total des suggestions qui était affiché. En cliquant sur ce compteur, on arrivait sur une page montrant les suggestions que l'on pouvait gérer, c.-à-d. celles qui sont associées à sa bibliothèque de rattachement. L'affichage des suggestions sur la page d'accueil est désormais plus précis. On affiche le nombre des suggestions de sa bibliothèque ainsi que le nombre total de suggestions. Chaque compteur amène sur une page différente qui affiche le bon nombre de suggestions.

• Résultat Z39.50 — La page de résultat d'une recherche Z39.50 lancée depuis le module Acquisitions a été alignée sur la page résultat du module Catalogage. Deux colonnes étaient manquantes : Année et Edition.

• Liens vers rapports statistiques — La barre latérale du module Acquisitions a été enrichie de deux nouveaux liens vers les rapports statistiques Statistiques sur les acquisitions et Commandes par budget.

• Filtre Commandes permanentes — En recherche avancée des commandes, une boîte à cocher Commandes permanentes a été ajoutée à droite de la boîte de liste Statut de la commande. Cela permet de filtrer le résultat de la recherche sur les commandes permanentes.

Architecture

• Logs Plack — Les logs produits par Koha en mode Plack ont été améliorés. Il y a trois fichiers de logs au-lieu d'un seul : un fichier par interface, OPAC, Pro et API. Les logs sont désormais horodatés.

• Machinerie de traduction — Une nouvelle machinerie de traduction a été mise en place. Pour plus de détail sur le sujet, voir docs/development/internationalization.md.

• Refactorisation du code — On trouve dans Koha, beaucoup de code dupliqué. La refactorisation vise à regrouper ce code dupliqué afin de simplifier Koha, de le rendre plus maintenable et plus facile à faire évoluer par la suite :

  • Code gérant les adresses et les contacts
  • Recherche des règles de circulation
  • Etc.

Catalogage

• Résultat recherche après suppression d'une notice — Le workflow de la suppression de notices était jusqu'à présent le suivant : on lance une recherche ; on identifie une notice à supprimer ; on supprime tous ses exemplaires et la notice elle-même. Après quoi, on est ramené à la page de recherche avancée. Il n'y avait pas moyen de revenir au résultat de la recherche initiale et de poursuivre la suppression d'autres notices : il fallait reformuler sa recherche. Il est désormais possible de revenir au résultat initial. Après suppression de la notice, sur la page de recherche avancée, un nouveau lien est affiché : Retour au résultat.

• Résultat des recherches d'autorités — L'affichage des pages de résultat des recherches d'autorités a été amélioré. Le lien vers le détail d'une notice est fait sur la vedette matière plutôt que sur un texte "détail". Une colonne séparée affiche le type des autorités. Des améliorations de même nature sont disponibles dans les plugins de catalogage des autorités, dans les modifications et dans les suppressions par log.

• Envoi d'un fichier en Catalogage — En catalogage, si un champ (comme 856$u) est lié au plugin upload.pl, il est possible d'associer un fichier à une notice et d'envoyer le fichier sur le serveur Koha. Jusqu'à présent, pour ces champs, on affichait l'icône générique d'accès aux plugins de catalogage : crayon. Désormais, on affiche un lien spécifique : Télécharger.

• Page de catalogage adaptative — La fenêtre de catalogage a été améliorée pour s'adapter à la taille d'affichage de l'écran du Catalogueur, y compris s'il s'agit d'un écran de petite taille.

• Séquence de remplacement <> — Dans les grilles de saisie, on peut définir des valeurs par défaut contenant des séquences de remplacement. Dans un champ Date, <<MM>> sera remplacée par le mois du jour et <<YYYY>> sera remplacée par l'année courante sur quatre chiffre. Une nouvelle séquence a été ajouté, <<YY>> qui sera remplacée par les deux derniers chiffres de l'année en cours.

• Vue en dernier — Sur la page de détail d'une notice biblio, dans le tableau qui affiche les exemplaires, une nouvelle colonne affiche l'information Vue en dernier. Cette colonne peut être masquée.

• Création de valeurs autorisées depuis le Catalogage — En Catalogage, quand on est sur un champ contrôlé par une liste de valeurs autorisées, il n'était pas possible de saisir une valeur qui ne se trouve pas déjà dans la liste. On était obligé d'aller en Administration pour ajouter une valeur. Désormais, quand on est en catalogage, et si on dispose de la permission manage_authorised_values, quand on saisit manuellement une valeur et que celle-ci ne se trouve pas dans la liste, Koha propose de la créer. Une boîte de dialogue s'affiche dans laquelle on peut saisir la valeur autorisée et sa description.

• Image de couverture exemplaire — Quand la préférence LocalCoverImages est activée, on peut désormais attacher une image à chaque exemplaire d'une notice. Cela peut-être utile pour un périodique par exemple.

Circulation

• Durée de prêt des exemplaires très demandés — La préférence decreaseLoanHighHolds permet d'activer un mécanisme de réduction de la durée des prêts pour les exemplaires qui ont un grand nombre de réservations. On définit une nouvelle durée de prêt avec la préférence decreaseLoanHighHoldsDuration. Ce mécanisme est global. Il peut désormais être affiné par bibliothèque, type de doc et de lecteur, via la matrice des règles de circulation. Une nouvelle colonne y a été ajoutée : Réduire durée de prêt pour réservations élevées (jours). Le nombre de jours indiqué dans cette colonne remplacera la valeur par défaut définie via la préférence système.

• N° d'inventaire — Sur la fiche d'un lecteur, en cliquant sur Imprimer > Imprimer le résumé, on imprime un résumé des prêts du lecteur. Le tableau contenant les prêts a une colonne supplémentaire : N° d'inventaire.

• Prêts par lot avec date forcée — On peut désormais fixer une date forcée de retour pour les prêts par lot. La fonctionnalité de prêts par lot est activée au moyen de la préférence BatchCheckouts. Les lecteurs appartenant aux catégories spécifiées dans la préférence BatchCheckoutsValidCategories ont un onglet Prêt par lot qui s'affiche sur leur fiche lecteur. Dans cet onglet, on peut saisir une liste de codes à barres (ou l'envoyer depuis un pad RFID). Tous les exemplaires seront prêtés, les prêts étant forcés au besoin si l'opérateur a la permission force_checkout. Pour les lecteurs de type statistique, les transactions seront marquées comme à usage local. Si la préférence SpecifyDueDate est activée, une nouvelle option est ajoutée à cet onglet, comme pour les prêts à l'unité : Date de retour forcée.

• Date de retour manuelle en renouvellement — Sur la page Circulation > Renouvellement, la date de renouvellement peut être manuellement forcée si la préférence SpecifyDueDate est activée.

• Volume de l'exemplaire sur les prêts d'un lecteur — La table des prêts d'un lecteur est enrichie du champ Volume (items.copynumber). Il s'affiche dans une nouvelle colonne placée à droite de la colonne contenant les cotes. L'affichage de ce champ est paramétrable en Administration > Paramétrage des tables > Adhérents > issues-table, champ copynumber.

• Blocage des prêts pour une famille débitrice — Il y avait déjà dans Koha un mécanisme permettant de bloquer le droit au prêt d'un garant si l'ensemble des personnes pour lesquelles il se porte caution doivent un montant supérieur à un seuil fixé par la préférence NoIssuesChargeGuarantees. On peut maintenant, si on le souhaite, bloquer les prêts, à la fois du ou des garants, ainsi que de toutes les personnes pour lesquelles ils se portent caution si le total des amendes dues est supérieur au montant fixé par la nouvelle préférence NoIssuesChargeGuarantorsWithGuarantees. Par exemple, dans le cas d'une famille avec deux parents (garants) et deux enfants, non seulement les parents sont interdits de prêt, mais aussi les enfants, s'ils doivent tous un total supérieur au seuil fixé.

• Statut de l'exemplaire en Demande d'article — Sur la page des Demandes d'articles, une colonne a été ajoutée qui affiche le statut des exemplaires : En prêt, Réservé, Pas empruntable, En commande.

• Collection dans une colonne séparée en Retours — Sur la page des retours, la Collection (ccode) des exemplaires est désormais affichée dans une colonne séparée. L'affichage ou non de cette colonne est contrôlé en Administration > Paramétrage des tables > Circulation > return > ccode.

• Opérateur de prêt dans l'historique — Sur la page de l'historique des prêts d'une notice ou sur celle de l'historique des prêts d'un lecteur, on n'affiche pas l'identité du bibliothécaire (ou l'automate) qui a effectué le prêt. Certains utilisateurs de Koha allaient rechercher l'information dans la table des logs, au moyen de requêtes SQL passablement complexes. Koha peut désormais enregistrer cette information (qui a fait le prêt) si la nouvelle préférence système RecordIssuer est activée. L'identifiant de l'opérateur (pris dans la table borrower) est enregistré dans un nouveau champ issuer_id qui a été ajouté aux tables issues et old_issues. Quand la préférence RecordIssuer est activé, les historiques des prêts affichent une colonne supplémentaire Prêté par qui contient, quand l'information est disponible, le nom de l'opérateur de prêt et un lien vers sa fiche.

• Compte lecteur bloqué — Avec la préférence système FailedLoginAttempts, un compte lecteur est automatiquement bloqué si des tentatives de connexion à l'OPAC ont échoué un certain nombre de fois. La mention n'apparaissait pour les bibliothécaires en interface pro que sur la page de détail du compte lecteur, pas sur la page de prêts, ni sur aucune autre. Désormais, le blocage est affiché sur toutes les pages du module Adhérent (tous les onglets).

• Renouvellements invisibles — Un exemplaire peut être renouvelé de façon invisible, par le lecteur depuis l'OPAC, ou bien parce que le renouvellement automatique a été paramétré. Cela peut permettre de cacher la perte d'un livre. On distingue les renouvellements visibles (fait par un opérateur de prêt ou par un automate), des renouvellements invisibles. Une nouvelle fonctionnalité permet de traiter spécifiquement ces deux catégories de renouvellement. On active cette fonctionnalité avec la préférence UnseenRenewals. Quand la préférence est activée, la matrice des règles de circulation dispose d'une colonne supplémentaire : Renouvellements invisibles. On y indique le nombre maximum de renouvellements de ce type au-delà desquels le renouvellement sera bloqué. Le champ existant de la table des prêts issues.renewals stocke les renouvellements visibles. Un nouveau champ issues.unseen_renewals contient les renouvellements invisibles.

• useDaysMode dans la matrice des règles de circulation — La préférence useDaysMode permet de choisir un mode de calcul de la date de retour des prêts qui tienne compte du calendrier et des dates de fermeture de la bibliothèque. C'est un paramètre global. On peut désormais l'affiner dans la matrice des règles de circulation. Pour chaque règle, on choisit de conserver le fonctionnement par défaut défini dans la préférence ou bien de fixer une règle de calcul spécifique.

• Quarantaine — Les possibilités de gestion de la mise en quarantaine des exemplaires après leur retour ont été étendues. On utilisait jusque-là les préférences UpdateNotForLoanStatusOnCheckin et TrapHoldsOnOrder. On dispose maintenant d'une nouvelle préférence SkipHoldTrapOnNotForLoanValue. On y place des valeurs de statut d'exemplaire (notforloan) pour lesquelles la mise à disposition des réservations n'est pas faite au retour de l'exemplaire. Cela affine ce que l'on pouvait déjà faire avec TrapHoldsOnOrder qui déterminait un comportement global.

• Documents multi-supports — Le champ d'un exemplaire items.materials peut contenir le nombre de supports physiques d'un document, par exemple un livre et deux DVD. Ce champ est couramment utilisé en MARC21 et lié à la zone 952$3. On ne le trouve généralement pas dans les Koha Unimarc. Une nouvelle préférence CircConfirmParts a été ajoutée qui permet de renforcer le contrôle du prêt de ces exemplaires. Quand le champ est renseigné, il est affiché et visible par l'opérateur de prêt. Quand la préférence est activée, le prêt est bloqué et le bibliothécaire doit le confirmer.

• Réservations à traiter — Sur la page des réservations à traiter, trois champs supplémentaires sont affichés : Mention d'édition (205$a), Année d'édition (201$a) et Année du copyright.

• Finalisation d'un transfert — Un transfert d'une bibliothèque à une autre est finalisé par un retour : quand l'exemplaire arrive à la bibliothèque destination, son code à barres doit être scanné en Circulation > Retour. Aucun message n'était affiché pour indiquer que ce n'était pas un retour à proprement parler mais la fin d'un transit. Un message spécifique est désormais affiché.

• Priorité aux réservations locales — Il existe dans Koha un mécanisme qui permet de donner la priorité aux réservations faites par des lecteurs dont la bibliothèque d'appartenance ou de retrait correspond à la bibliothèque détentrice ou d'appartenance des exemplaires. Ce mécanisme est contrôlé par trois préférences système : LocalHoldsPriority, LocalHoldsPriorityPatronControl et LocalHoldsPriorityItemControl. Ce mécanisme a été affiné. On peut désormais exclure de la priorité spécifiquement certains exemplaires ou certaines catégories de lecteur.

  • Exemplaires — Un champ exclude_from_local_holds_priority a été ajouté à la table des exemplaires. Dans l'onglet Exemplaires d'une notice, une section Priorité a été ajoutée : elle contient une bascule oui/non Exclure de la priorité locale.

  • Lecteurs — En Administration > Catégorie adhérent, sur la page de chaque catégorie, une nouvelle option a été ajoutée Exclure de la priorité locale.

• Réservation non prioritaire — Une réservation peut désormais être faite dans l'interface pro et marquée comme non prioritaire. Une réservation non prioritaire ne bloque pas le renouvellement de l'exemplaire.

• Statut endommagé — Sur la page des Retours, si un exemplaire est endommagé, son statut est affiché.

• Non remboursement — Quand un exemplaire est marqué comme perdu, le lecteur peut se voir imputer une amende. Si le lecteur rend l'exemplaire, l'amende lui est remboursée. Une nouvelle préférence NoRefundOnLostReturnedItemsAge permet de fixer un nombre de jours de retard au-delà duquel le remboursement ne sera pas effecuté.

Adhérents

• Dédoublonnage en création de lecteur — Quand on crée un nouveau lecteur, Koha essaie de déterminer si le lecteur n'existe pas déjà dans le système. Jusqu'à présent, le dédoublonnage se faisait sur les champs : nom, prénom et date de naissance. Désormais on peut choisir soi-même les champs qui entrent dans la clé de dédoublonnage au moyen de la préférence PatronDuplicateMatchingAddFields.

• Suppression d'un lecteur ayant des suggestions — Dans l'interface pro, si on essaie de supprimer un lecteur qui a des suggestions d'achat en attente, on affiche désormais un message d'avertissement.

• RenewalSendNotice — Cette préférence permet de paramétrer l'envoi d'un courriel au lecteur quand il prolonge des prêts, à la condition que par ailleurs il ait choisi dans ses préférences de notification l'envoi d'un courriel quand il réalise un prêt. Désormais, dans le table des Préférences de notification le texte affiché tient compte de cette préférence :

  • Si RenewalSendNotice est désactivée, on affiche : Prêt d'exemplaire.
  • Si RenewalSendNotice est activée, on affiche : Prêt et renouvellement d'exemplaire.

• Auto-validation — Les lecteurs peuvent modifier leur fiche d'information à l'OPAC. Les modifications ne prennent pas effet immédiatement. Elles doivent être validées par un bibliothécaire dans l'interface pro. Désormais, grâce à la nouvelle préférence AutoApprovePatronProfileSettings, les modifications faites par le lecteur peuvent être validées automatiquement.

• Fichiers attachés — La préférence EnableBorrowerFiles permet d'attacher des fichiers aux fiches des lecteurs. Ces fichiers sont visibles dans un onglet distinct : Fichiers. L'onglet Détails du lecteur a été étendu pour afficher directement les fichiers du lecteurs, chaque fichier étant cliquable. Un lien Gérer permet d'accéder à l'onglet de gestion des fichiers attachés.

• Ville et état — En résultat d'une recherche de lecteur, les champs Nom, Prénom, Adresse et Email étaient affichés. Cela pouvait être insuffisant pour identifier les lecteurs en cas d'homonymie. Deux champs ont été ajoutés au tableau des résultats : Ville et Etat.

• Force des mots de passe par catégorie — La force des mots de passe des lecteurs est déterminée par les préférences minPasswordLenth et RequireStrongPassword. On peut désormais renforcer ou relâcher ces critères par catégorie de lecteur. En allant en Administration > Catégorie d'adhérent, vous noterez la présence dans la définition des catégories deux nouveaux champs : Taille minimale du mot de passe et Exige un mot de passe fort.

• Genre — Sur la fiche d'un lecteur, il était possible de choisir trois genres : Femme, Homme et Non spécifié. Ces formulations peuvent être considérées comme inappropriées par certains lecteurs. Une quatrième option a été ajoutée : Autre.

• Garant non lecteur — Le garant d'un lecteur peut être un lecteur Koha ou une personne qui n'a pas de fiche lecteur dans Koha. La disposition de la fiche d'un lecteur a été améliorée pour bien distinguer visuellement ces deux catégories de garant.

• Lecteurs pro — Les lecteurs de Koha peuvent aussi être des utilisateurs de Koha. Des permissions leur sont attribuées pour accéder à tout ou parties des fonctionnalités de l'interface pro. Quand on est la fiche d'un lecteur, deux icônes ont été ajoutées qui s'affichent pour identifier ces lecteurs :

  • utilisateur pro : une icône représentant un bouclier 🛡
  • super-bibliothécaire (superlibrarian) : une icône représentant un éclair 🗲

• Âge — L'âge des lecteurs est affiché partout où c'est nécessaire, par exemple en Circulation, au moment de la recherche du lecteur. Cela peut permettre de distinguer rapidement les enfants et les parents.

OPAC

• Choix de l'icône Type de document — En MARC21, la feuille de style par défaut de la page de résultat affiche le type de document qui se trouve dans la zone codée 008, ainsi qu'une icône. Une nouvelle préférence BiblioItemtypeImages permet de choisir d'afficher l'icône du type de document de niveau bibliographique qui se trouve dans la zone 942$c.

• Langue des notifications — Sur la fiche d'un lecteur, en interface pro, il est possible de choisir la langue qui sera utilisée pour les notifications adressées à ce lecteur. Une option a été ajoutée à l'OPAC pour permettre au lecteur de changer lui-même cette langue.

• Boostrap 4 — La version de Bootstrap de l'OPAC est passée de la version 2.3.1 à la version 4.5.0. Si votre OPAC est personnalisé au moyen de CSS et de Javascript, il peut être nécessaire de mettre à jour certaines de ces personnalisations.

• Historique des réservations — Une nouvelle préférence système OPACHoldsHistory permet d'afficher à l'OPAC l'historique des réservations d'un lecteur, c.-à-d. l'ensemble des réservations qui ne sont plus actives, soit qu'elles aient été honorées soit qu'elles aient été annulées.

• Accessibilité — L'accessibilité de l'OPAC a été améliorée en ajoutant là où c'était nécessaire des marqueurs html. Il s'agit souvent de balises de titre (<h1>, <h2>, etc.) qui doivent se suivre selon une certaine hiérarchie pour permettre aux personnes utilisant des dispositifs d'aide à la lecture de naviguer dans les pages de l'OPAC.

• Accessibilité clavier — L'accessibilité de l'OPAC a été améliorée pour les personnes qui utilisent leur clavier. Ces personnes ont l'habitude de presser la touche Tab pour passer d'un lien à un autre sur la page. Désormais, lorsqu'on appuie une première fois sur Tab, un message est affiché sur la page : Passer au contenu principal. En appuyant sur la touche Entrée, la page défile jusqu'au début de la portion de la page qui contient de l'information, par exemple le résultat d'une recherche, sous la barre de recherche.

• Préférences système ➔ annonces — Les préférences système permettant de remplir des zones d'affichage de l'OPAC continuent de migrer en tant qu'annonces. On les retrouve dans Outils > Annonces. Trois préférences sont concernées : OpacCredits, OpacCustomSearch et OpacLoginInstructions.

• Télécharger Panier — Dans la boîte de visualisation du panier, le bouton Télécharger ouvrait une boîte de dialogue séparée. Maintenant, ce bouton ouvre un menu permettant de choisir directement le format du fichier téléchargé.

• Variables Javascript contenant la requête — Des variables Javascript ont été ajoutées aux pages de l'OPAC. Elles contiennent des infos sur la requête lancée. Cela permettra à certaines bibliothèques d'intégrer des plugins utilisant ces variables ou bien de programmer directement en Javascript des fonctionnalités supplémentaires (lancer la recherche dans un autre système par exemple). Trois variables : query_desc, querystring et query_cgi.

• Tri des prêts — Un lecteur connecté à l'OPAC peut voir la liste de ses prêts dans un tableau. Désormais, le lecteur peut trier ses prêts sur la colonne Renouvellements restants.

• Validation du mot de passe dans la navigateur — Dans la page de réinitialisation du mot d'un lecteur, la saisie du nouveau mot est directement validée dans le navigateur (longueur, correspondance), sans avoir à envoyer le formulaire au serveur Koha.

• <meta name="description"> — Les moteurs de recherche comme Google affichent sur leur page de résultat des liens vers des pages ainsi que l'information qui se trouve dans la balise <meta name="description"> de ces pages. L'OPAC de Koha ne proposait pas cette balise. Désormais on peut spécifier son contenu dans la préférence système OpacMetaDescription.

• Cacher les profils CSV — Jusqu'à présent, tous les profils CSV définis en interface pro étaient visibles à l'OPAC dans l'option de téléchargement du panier. Désormais, les profils CSV disposent d'un nouveau paramètre qui permet de ne pas les afficher à l'OPAC.

Automates de prêt

• Réservations — Jusqu'à présent, quand un document est rendu en utilisant un automate, si le document a une réservation, la réservation est immédiatement honorée et l'exemplaire passe au statut Mis de côté. Une notification est envoyée aussitôt au lecteur. Si bien que pour certaines bibliothèques, il arrive que le lecteur se présente pour retirer le livre alors que celui-ci n'est pas encore prêt. Une nouvelle préférence HoldsNeedProcessingSIP permet de remédier à ce problème. Quand cette préférence est activée, l'exemplaire ne passe pas immédiatement au statut Mis de côté et aucune notification n'est envoyée. L'exemplaire passe au statut Réservation à traiter.

• Champ CR — Le champ SIP2 CR était renseigné jusqu'à présent avec le contenu du champ code de collection : items.ccode. CR devient paramétrable. Dans le fichier de configuration du Serveur SIP2, un paramètre cr_item_field a été ajouté. Il peut contenir les valeurs : ccode, shelving_location et permanent_shelving_location.

• Envoi de tout champ — Tout champ de l'exemplaire peut désormais être renvoyé par le Serveur SIP2 en ajoutant au fichier de configuration des paramètres de la forme suivante :

  <item_field field="XX" code="<item field 1>" />

• Nouveaux statuts — Support par le Serveur de nouveaux statuts de la norme SIP2 : En transit (10), Retour demandé (11) et Perdu (12).

• Blocage du retour des exemplaires réservés — Certaines bibliothèques souhaitent interdire le retour via les automates des exemplaires sur lesquelles des réservations ont été placées. Cela est désormais possible au moyen d'un nouveau paramètre du fichier de configuration du Serveur SIP2 : no_holds_checkin.

Outils

• Citation du jour — La préférence QuoteOfTheDay a été modifiée afin de permettre de choisir l'emplacement où afficher les citations : à l'OPAC, à l'interface pro, ou au deux.

• Editeur Wysiwyg / Texte — Les annonces sont modifiées dans un éditeur Wysiwyg. Pour les administrateurs Koha qui maîtrisent bien le langage HTML, un éditeur Texte est préférable parce qu'il permet de générer un code HTML plus élaboré et qui s'intègre mieux à Koha. Une nouvelle préférence NewsToolEditor permet de choisir l'éditeur par défaut des annonces : Wysiwyg ou Texte. Par ailleurs, sur le tableau des annonces, le bouton Modifier affiche aussi une flèche qui permet de sélectionner l'éditeur alternatif.

• Inventaire/récolement — L'outil d'inventaire/récolement traite des exemplaires. Ces exemplaires sont identifiés au moyen de leur code à barres. On les envoie à Koha dans un fichier texte. On peut maintenant également les scanner directement dans une zone de saisie de l'outil de récolement.

• Modification par lot des dates de retour — L'outil de modification par lot des dates de retour a été ajouté à Koha à l'occasion de la crise de la COVID-19. Il permet de sélectionner des lots d'exemplaires et de modifier leur date de retour. L'outil fonctionne en deux temps : 1) affichage des exemplaires sélectionnés et 2) modification de la date de retour. Le temps d'affichage des exemplaires sélectionnés peut être très long si la sélection des prêts renvoie un grand nombre d'exemplaires. Une nouvelle option permet de sauter l'étape 1 et de passer directement à l'étape 2 de modification des exemplaires.

• Calendrier — Une nouvelle option du calendrier permet, en ajout/modification/suppression d'un jour fermé d'une bibliothèque, de reporter l'action à toutes les bibliothèques.

• Visualiseur des logs — Différentes options de filtrage et de visualisation ont été ajoutées à l'outil de consultation des logs du système.

  La zone de filtrage par bibliothécaire fonctionne maintenant avec autocomplétion : on commence à taper le début d'un nom (ou autre info) et Koha propose des noms d'adhérents.

  Quand on visualise l'historique des modifications d'une préférence système, il est désormais possible d'en sélectionner deux versions puis de cliquer sur l'option Comparer : une boîte de dialogue s'ouvre qui visualise ce qui a changé entre les deux versions de la préférence.

Divers

• build_oai_sets.pl — Le script build_oai_sets.pl construit les SET OAI définis en Administrations > Configuration des Sets OAI. Le script a été amélioré pour inclure les notices supprimées.

• Réserves de cours — Un nouvel outil permet de supprimer des réserves de cours une liste d'exemplaires identifiées par leurs codes à barres. Toutes les réserves de cours contenant ces exemplaires sont mises à jour.

• Images de couverture en pro — Quand plusieurs sources d'images de couverture sont choisies, la page de détail d'une notice en interface pro affiche désormais les images dans un unique emplacement, dans lequel on peut faire défiler les images quand il y en plusieurs.

• Notification sans destinataire — Si un lecteur n'a pas d'adresse email, les notifications de retard qui lui sont destinées sont envoyées à l'adresse email de sa bibliothèque d'appartenance ou à l'adresse globale définie dans la préférence KohaAdminEmailAddress. Une nouvelle préférence RedirectAddressForFailedOverdueNotices a été ajoutée afin que ces notifications de retard soient envoyées à une adresse spécifique.

• process_message_queue.pl -c — Un paramètre -c a été ajouté au script process_message_queue.pl qui traite la file d'attende des notifications à envoyer par email. Avec ce paramètre, on peut spécifier le code d'une notification : seuls les courriels de ces notifications seront envoyés.

• Date modification des notifications — Les notifications enregistrent désormais la date à laquelle elles ont été modifiées pour la dernière fois.

• TT dans les titres — Le contenu des notifications est formaté au moyen au moyen du système de templating Template Toolkit (TT). Désormais, le titre des notifications peut également être formaté avec TT. Vous pourrez avoir par exemple dans la zone titre de la notification de retard :

  Bonjour [% borrower.firstname %]

• Ancienneté des exemplaires — Les exemplaires ont un champ new_status qui permet de gérer leur ancienneté. Un script, qui peut être exécuté quotidiennement, automatic_item_modification_by_age.pl, permet de modifier le contenu de ce champ en fonction de règles définies en Outils > Modification automatique d'exemplaires par ancienneté. Ce champ est désormais cherchable en Recherche d'exemplaires.

• Plugin — Les possibilités des plugins Koha ont été étendues :

  • Prêt/Retour — Les plugins peuvent être appelés après les transactions de prêt/retour. Cela peut permettre par exemple d'avoir un plugin verrouillant/déverrouillant des étiquettes RFID.

  • Réservation — Idem précédent pour les réservations.

  • Renouvellement — Idem précédent pour les renouvellements.

  • XSLT — Mécanisme pour envoyer des variables aux feuilles de style des pages de résultat et de détail.

• Liens Koha => MARC — Dans les versions récentes de Koha, il n'est plus possible de modifier les liens entre les champs de la base de données et les champs MARC à partir de la page de modification des grilles de saisie. Ce mode de fonctionnement est désormais clairement expliquer partout où c'est nécessaire.

• Sélection de champs en Préférences système — Il y a des préférences système dans lesquelles on doit saisir une liste de champs de la base de données séparés par une barre verticale. C'est la cas par exemple de BorrowerMandatoryField qui permet de choisir les champs obligatoires de la fiche des lecteurs. Désormais, pour cette préférence, et pour un certain nombre d'autres, la saisie n'est plus manuelle. On choisit les champs dans une liste prédéfinie et complète.

• Serveur OAI

  • marcxml/marc21 — Le Serveur OAI de Koha, quand il fonctionne en mode étendu, peut publier des formats de métadonnées spécifiques. Les enregistrements renvoyés sont générés à partir des notice MARCXML qui sont transformées au moyen d'une feuille XSL. Les formats marc21 et marcxml ne pouvaient utiliser auparavant cette transformation. C'est désormais possible. Cela permet de présenter deux formats standards, tout en filtrant/reformatant certains champs si nécessaire.

  • SETS — Les SETS sont mis à jour automatiquement si la préférence OAI-PMH:AutoUpdateSets est activée. Mais si les exemplaires des notices sont modifiés, les SETS ne sont pas mis à jour. Or cela peut être nécessaire pour les SETS qui utilisent des infos de niveau exemplaire dans leurs règles de mapping. Une préférence système a été ajoutée à cet effet : OAI-PMH:AutoUpdateSetEmbedItemData. Quand elle est activée, la modification d'un exemplaire déclenche la mise à jour des SETS.