Koha 24.11

lundi 25 novembre 2024

Noël avant l'heure, des nouveautés comme s'il en pleuvait, cette version de Koha est particulièrement riche : 10 nouvelles fonctionnalités, 184 améliorations et 647 corrections de bugs. Koha sait désormais moissonner des entrepôts OAI-PMH pour alimenter son catalogue. Les réservations programmées gagnent beaucoup en maturité. Le module de PEB fonctionne sans extension, grâce à un formulaire Standard intégré. À l'OPAC, l'adhérent dispose d'une carte de bibliothèque à présenter à la banque de prêt et peut citer une notice dans différents styles bibliographiques. L'interface passe à Bootstrap 5.

Catalogage

Moissonnage OAI-PMH 🆕

Koha était déjà un serveur OAI-PMH : d'autres applications pouvaient moissonner son catalogue. Il peut désormais être aussi un client et moissonner des entrepôts OAI-PMH pour importer leurs notices dans son catalogue.

Les entrepôts se définissent dans Administration › Entrepôts OAI. Pour chacun, on indique :

son adresse (endpoint),
éventuellement un ensemble (set), pour ne moissonner qu'une partie de l'entrepôt,
le format des données : Dublin Core (oai_dc) ou MARCXML,
le type de notices : bibliographiques ou d'autorité,
éventuellement une feuille XSLT pour transformer les notices reçues.

Les notices Dublin Core sont converties en UNIMARC ou en MARC21 par des feuilles XSLT fournies avec Koha.

Le moissonnage est lancé par le script misc/cronjobs/harvest_oai.pl, à programmer par l'administrateur du serveur, entrepôt par entrepôt. Koha garde la trace de chaque notice moissonnée, par son identifiant OAI. Au moissonnage suivant, une notice nouvelle est ajoutée au catalogue, une notice modifiée dans l'entrepôt depuis le dernier moissonnage est mise à jour et une notice supprimée dans l'entrepôt est supprimée de Koha. L'option --days limite le moissonnage aux notices modifiées ces derniers jours. L'option --force réimporte toutes les notices.

À la fin de chaque moissonnage, un rapport (ajouts, mises à jour, suppressions, erreurs) peut être envoyé par courriel à l'adresse indiquée dans la nouvelle préférence système OAI-PMH:HarvestEmailReport, au moyen de la notification OAI_HARVEST_REPORT.

Plus

Liens UNIMARC entre autorités et ISNI — Quand on lie une autorité à une autre autorité (zones 5XX), Koha recopie désormais l'ISNI de l'autorité liée (010$a) dans le $o de la zone de lien. Cela vaut pour les noms de personne, de collectivité et de famille.
Modèles de modification MARC — Un modèle peut copier le contenu d'une zone de contrôle dans une sous-zone, par exemple le 001 dans le 035$a.
Paquets — Un paquet est un exemplaire qui en regroupe d'autres et circule comme un tout : une mallette pédagogique, un kit livre et CD, une exposition itinérante, etc. Au retour, Koha fait vérifier que tous les exemplaires du paquet sont présents. Quand on ajoute un exemplaire à un paquet, une case Ajout d'un lien MARC permet désormais de lier aussi les notices : Koha ajoute à la notice de l'exemplaire une zone de lien vers la notice du paquet, 461 en UNIMARC ou 773 en MARC21.
Groupes d'exemplaires — Quand la préférence système EnableItemGroups est activée, les exemplaires d'une notice peuvent être répartis en groupes. C'est utile pour une œuvre en plusieurs volumes décrite par une seule notice : un groupe par tome, chacun réunissant les exemplaires de ce tome. Le tableau des exemplaires indique le groupe de chaque exemplaire et, avec EnableItemGroupHolds, un adhérent peut réserver le premier exemplaire disponible d'un groupe, c'est-à-dire d'un tome. Les groupes s'affichent selon leur ordre d'affichage. Un groupe peut être créé directement depuis le formulaire d'ajout d'un exemplaire (Ajouter à un groupe d'exemplaires). Jusqu'ici, son ordre d'affichage ne pouvait être fixé qu'ensuite, dans l'onglet Groupes d'exemplaires de la notice. Le formulaire a désormais un champ Ordre d'affichage.
Inventaire — L'export CSV peut être demandé depuis la page de résultats de l'inventaire et plus seulement avant de le lancer.
XSLT pour les autorités — La nouvelle préférence système AuthorityXSLTDetailsDisplay permet d'afficher la page de détail d'une autorité, dans l'interface professionnelle, au moyen d'une feuille XSLT personnalisée, comme c'était déjà possible à l'OPAC. Le chemin peut contenir {langcode} et {authtypecode}, pour avoir une feuille par langue et par type d'autorité.
MARC21 — Les grilles de catalogage MARC21 bibliographiques et d'autorité sont mises à jour (nouvelles installations seulement). La zone 005 n'est plus obligatoire dans les grilles bibliographiques, puisque Koha la remplit lui-même.

Réservations programmées

La réservation programmée d'un exemplaire, pour une période donnée, est apparue dans la version 23.11. Elle est très enrichie :

Réservations programmées à préparer 🆕 — Un nouveau rapport du module Circulation liste les réservations programmées qui vont commencer, pour sortir les exemplaires des rayons et les préparer pour l'adhérent. C'est le pendant de la liste des réservations à mettre de côté.
Délais avant et après — On peut définir un délai avant et après chaque réservation programmée. Pendant ces délais, l'exemplaire ne peut être ni prêté ni réservé, ce qui laisse le temps de le transférer ou de le vérifier.
Durée maximale — Une réservation programmée ne peut pas dépasser la durée de prêt maximale permise par les règles de circulation, renouvellements compris. Le calendrier met cette durée en évidence.
Types de document — On peut indiquer, par type de document, si ses exemplaires peuvent faire l'objet d'une réservation programmée. Le réglage de l'exemplaire l'emporte sur celui du type de document.
Statut et motif d'annulation — Une réservation programmée a désormais un statut (nouvelle, annulée, terminée) : elle n'est plus supprimée quand elle est annulée ou honorée, ce qui permettra des statistiques. Lors d'une annulation, le personnel peut choisir un motif, dans la nouvelle liste de valeurs autorisées BOOKING_CANCELLATION ou en texte libre.
Notifications — L'adhérent est averti de la création (BOOKING_CONFIRMATION), de la modification (BOOKING_MODIFICATION) et de l'annulation (BOOKING_CANCELLATION) de ses réservations programmées.
Fiche lecteur — Les réservations programmées expirées peuvent être affichées, avec un indicateur Expirée ou Active.

Circulation

Affichage immédiat des prêts — Sur la page de prêt, la liste des prêts en cours ne s'affiche qu'après un clic, sauf si l'on coche Toujours afficher les prêts immédiatement, un réglage propre à chaque navigateur. La nouvelle préférence système AlwaysLoadCheckoutsTable l'impose à tous. La préférence LoadCheckoutsTableDelay, apparue en 23.11, peut retarder ce chargement de quelques secondes, pour pouvoir prêter sans attendre quand la liste est longue.
Confirmations mémorisées — Lors d'un prêt, un même avertissement (par exemple une amende impayée) peut s'afficher à chaque exemplaire. Le personnel peut maintenant cocher une case pour ne plus avoir à le confirmer tant qu'il traite le même adhérent.
Limite d'amendes par catégorie — Les montants d'amendes au-delà desquels le prêt est bloqué (préférences noissuescharge, NoIssuesChargeGuarantees et NoIssuesChargeGuarantorsWithGuarantees) peuvent être définis par catégorie d'adhérent.
Retours contestés — Un adhérent affirme avoir rendu un exemplaire que Koha considère toujours en prêt : c'est une réclamation de retour. Cette fonctionnalité ne dépend plus d'un statut de perte particulier : le statut de perte de l'exemplaire est conservé et peut être modifié. Quand la réclamation est résolue, une case permet de rembourser les frais de perte déjà facturés.
Remboursement des frais de perte — Avec la nouvelle préférence système NoRefundOnLostFinesPaidAge, un exemplaire perdu retrouvé n'est pas remboursé si les frais de perte ont été payés depuis plus d'un certain nombre de jours.
Renouvellement — Les exemplaires à rendre le jour même sont présélectionnés pour le renouvellement, comme les exemplaires en retard.
Rappels — Deux notifications s'ajoutent aux préférences de messagerie de l'adhérent : exemplaire rappelé à retirer (PICKUP_RECALLED_ITEM) et exemplaire rappelé à rendre (RETURN_RECALLED_ITEM).
Retards — Le rapport des retards affiche la date du prêt.

Réservations

Calcul de la file des réservations — La file des réservations indique à chaque site les exemplaires à sortir des rayons pour satisfaire les réservations en attente. Pour chaque notice réservée, Koha cherche l'exemplaire disponible le plus approprié. Ce calcul est refait entièrement, en général toutes les heures, par le script misc/cronjobs/holds/build_holds_queue.pl. Quand les réservations se comptent par dizaines de milliers, il peut durer longtemps. La nouvelle préférence système HoldsQueueParallelLoopsCount fixe le nombre de processus qui se partagent le travail : les notices réservées sont réparties entre eux et traitées en même temps. La valeur par défaut, 1, conserve le fonctionnement habituel. Une valeur plus élevée accélère le calcul, mais charge davantage le serveur : elle ne devrait pas dépasser le nombre de processeurs disponibles. Cette préférence ne concerne pas la mise à jour de la file en temps réel (préférence RealTimeHoldsQueue).
File des réservations — L'auteur, les informations de publication et la localisation ont leurs propres colonnes. On peut les masquer, ou trier la file par localisation. L'adresse électronique de l'adhérent est affichée.
Demandes d'annulation — La page d'accueil de l'interface professionnelle signale les réservations dont l'adhérent a demandé l'annulation.

Acquisitions

Commandes automatiques à partir de fichiers MARC 🆕 — Certains fournisseurs déposent régulièrement des fichiers MARC des documents commandés. Koha peut maintenant les traiter automatiquement : la préférence système MarcOrderingAutomation active la fonctionnalité, un compte pour les commandes MARC est défini pour chaque fournisseur et le script misc/cronjobs/marc_ordering_process.pl importe les notices, crée les exemplaires et les lignes de commande dans un nouveau panier. C'est l'équivalent, pour les fichiers MARC, de ce que Koha fait déjà pour EDIFACT.
Permissions des suggestions — Deux nouvelles permissions, suggestions_create et suggestions_delete, distinguent la création et la suppression des suggestions de leur gestion. Le personnel qui gérait les suggestions reçoit les nouvelles permissions lors de la mise à jour. La nouvelle préférence système SuggestionsLog journalise la création, la modification et la suppression des suggestions.
Recherche de commandes — Le formulaire de recherche de commandes est affiché sur la page d'accueil des acquisitions.
Factures — Sur la page de réception, le numéro de facture est un lien vers la facture.
Devises — On peut choisir de placer le symbole d'une devise avant ou après le montant.

PEB

Formulaire Standard intégré 🆕 — Le module de PEB nécessitait l'installation d'au moins un backend, c'est-à-dire une extension qui fournit le formulaire de demande et le lien avec un fournisseur. Le backend FreeForm est désormais intégré à Koha sous le nom de Standard : le module est utilisable dès que la préférence système ILLModule est activée. Les demandes FreeForm existantes sont transférées vers Standard lors de la mise à jour.
Journal — Le journal des demandes de PEB indique quel membre du personnel a effectué chaque action.

OPAC

Carte de bibliothèque 🆕

Avec la nouvelle préférence système OPACVirtualCard, le compte de l'adhérent à l'OPAC affiche son numéro de carte sous forme de code à barres. L'adhérent peut ainsi le présenter sur son téléphone à la banque de prêt ou à l'automate de prêt, sans sa carte. La préférence OPACVirtualCardBarcode fixe le type de code à barres : CODE39, CODE128, EAN-13, etc.

Citer une notice 🆕

Un étudiant ou un chercheur qui utilise un document doit le citer dans sa bibliographie, selon un style imposé par sa discipline ou son éditeur. Un nouveau bouton Citer, dans la barre d'outils de la page de détail d'une notice, à l'OPAC, ouvre une fenêtre qui présente la référence du document dans quatre styles courants : APA, Chicago, Harvard et MLA. Il n'y a plus qu'à la copier.

Koha construit ces références à partir de la notice. En UNIMARC, il lit :

les auteurs dans les zones 700, 701, 702, 710 et 711 ($a et $b),
le titre et le complément du titre en 200$a et 200$e,
le lieu, l'éditeur et la date de publication en 210$a, $c et $d.

Attention : la zone 214, qui remplace la 210 dans les notices récentes du Sudoc, n'est pas prise en compte. Pour ces notices, la référence ne contient ni lieu, ni éditeur, ni date.

Plus

Robots des moteurs de recherche — La nouvelle préférence système OpacMetaRobots indique aux moteurs de recherche s'ils peuvent indexer les pages de l'OPAC et suivre leurs liens.
Identifiant de connexion — La nouvelle préférence système OPACLoginLabelTextContent fixe le libellé du champ identifiant du formulaire de connexion : numéro de carte, identifiant, ou les deux.
Lien Bibliothèques — La nouvelle préférence système OPACShowLibraries permet de masquer le lien Bibliothèques sous la barre de recherche.
Tableau des exemplaires — Les colonnes vides (cote, date de retour, matériel d'accompagnement, nombre de prêts, code à barres, réservation) sont masquées.
Couvertures dans les résultats — Koha peut afficher des images de couverture provenant de plusieurs sources : images locales, Coce, Amazon, Google, Open Library, Syndetics, adresse personnalisée. Quand plusieurs sources sont activées, la page de résultats de l'OPAC affichait toutes les couvertures trouvées pour une notice les unes à côté des autres, ce qui encombrait la liste. Elle n'en affiche plus qu'une par notice, avec en dessous un point par couverture disponible : un clic sur un point affiche la couverture correspondante. Les images vides ou introuvables sont écartées. La page de détail d'une notice fonctionnait déjà ainsi.
QR code — Le QR code d'une notice utilise l'adresse canonique de la notice, plus courte : le code est plus simple à lire.
OverDrive — La nouvelle préférence système OPACOverDrive désactive l'intégration d'OverDrive sans effacer ses identifiants.
Adhérents expirés — La préférence système BlockExpiredPatronOpacActions permet maintenant de choisir les actions interdites à l'OPAC aux adhérents dont l'inscription a expiré : renouvellement, réservation, demande de PEB.
Lien vers un onglet du compte — On peut faire un lien direct vers un onglet du compte de l'adhérent, par exemple /cgi-bin/koha/opac-user.pl?tab=opac-user-holds pour ses réservations.

Adhérents

Prénom d'usage 🆕 — Un nouveau champ, Prénom d'usage (preferred_name), permet d'enregistrer le prénom sous lequel l'adhérent souhaite être appelé. C'est lui qui est affiché partout dans Koha. S'il est vide, le prénom est utilisé. Dans les notifications, firstname donne toujours le prénom et preferred_name le prénom d'usage.
Changement de mot de passe obligatoire — Quand le personnel inscrit un adhérent, il lui attribue souvent un mot de passe provisoire, qu'il lui communique. Ce mot de passe est connu du personnel, parfois facile à deviner et l'adhérent n'a aucune raison d'en changer. Avec la nouvelle préférence système ForcePasswordResetWhenSetByStaff, le mot de passe d'un compte créé dans l'interface professionnelle est considéré comme expiré dès sa création. À sa première connexion à l'OPAC, l'adhérent doit donc choisir un nouveau mot de passe avant d'accéder à son compte. Le réglage peut aussi se faire par catégorie d'adhérent, dans Administration › Catégories d'adhérents (Forcer la réinitialisation du mot de passe des nouveaux adhérents) : la catégorie suit la préférence système, ou l'impose, ou l'exclut. Les adhérents de la catégorie attribuée aux inscriptions en ligne (PatronSelfRegistrationDefaultCategory) ne sont pas concernés, puisqu'ils choisissent eux-mêmes leur mot de passe.
Restriction en cas d'échec des notifications — Avec la nouvelle préférence système RestrictPatronsWithFailedNotices et le script misc/cronjobs/restrict_patrons_with_failed_notices.pl, un adhérent dont les notifications par courriel ou SMS échouent reçoit automatiquement une restriction. Le personnel est ainsi invité à vérifier ses coordonnées.
Messages dans la modification d'adhérents par lot — On peut joindre des messages à la fiche lecteur d'un adhérent : une note interne, visible du seul personnel au moment du prêt, ou un message affiché à l'adhérent dans son compte à l'OPAC. L'outil Outils › Modification d'adhérents par lot permet désormais d'ajouter un même message, de l'un ou l'autre type, à tous les adhérents sélectionnés. Par exemple, un message OPAC aux adhérents d'une annexe qui ferme pour travaux. Il permet aussi de supprimer d'un coup tous les messages de ces adhérents, en cochant la case à côté du champ. Attention : cette suppression porte sur tous leurs messages, quel que soit leur type ou leur date.
Modification par lot depuis un rapport — Le résultat d'un rapport SQL proposait déjà, dans son menu Traitements par lot, la modification par lot des adhérents qu'il contient, à condition de renvoyer leur numéro de carte (cardnumber). Certaines bibliothèques n'attribuent pas de numéro de carte à tous leurs adhérents. Il suffit désormais que le rapport renvoie leur identifiant interne (borrowernumber).
Recherche d'adhérents — Quand la préférence système PatronAutoComplete est activée, la recherche d'adhérents du module Circulation ou Adhérents propose les adhérents correspondants dès les premières lettres saisies. Cette liste signale désormais, par une étiquette Expiré ou Suspendu, les adhérents dont l'inscription a expiré ou qui ont une restriction. On le voit avant même d'ouvrir la fiche lecteur, au moment de choisir l'adhérent pour un prêt.

Le tableau des résultats de la recherche d'adhérents (module Adhérents) peut afficher les champs statistiques Tri 1 et Tri 2 (sort1, sort2), que les bibliothèques utilisent librement, par exemple pour la classe d'un élève ou le service d'un agent. Ces colonnes sont masquées par défaut : on les affiche avec le bouton Colonnes du tableau, ou par défaut dans Administration › Paramétrage des tableaux.
Statut protégé — Seul un superbibliothécaire peut protéger un adhérent contre la suppression, ou lever cette protection.
Garants — Un adhérent d'une catégorie de type Personnel peut être garant d'autres adhérents.
Dernière activité — Koha peut enregistrer la date de dernière activité de chaque adhérent (borrowers.lastseen). Elle sert à repérer les adhérents inactifs, dans un rapport SQL ou avec l'option --last_seen du script delete_patrons.pl, qui supprime les adhérents inactifs depuis une date donnée. La préférence système TrackLastPatronActivityTriggers indique quelles actions mettent cette date à jour : connexion, prêt, renouvellement, retour, réservation, connexion par SIP2, etc. La création de la fiche lecteur ne figurait pas parmi ces actions. Un adhérent inscrit mais qui n'avait encore rien fait n'avait donc pas de date de dernière activité : il échappait aux rapports sur les adhérents actifs et inactifs. On peut désormais cocher Création d'un adhérent dans la préférence : la date de dernière activité est alors fixée dès l'inscription.

Notifications

Réinitialiser une notification — Un bouton Voir la version par défaut de l'éditeur de notifications affiche la version livrée avec Koha d'une notification et permet de revenir à cette version.
Amendes d'un retard — Dans une notification de retard, [% overdue.overdue_fines.total_outstanding | $Price %] donne le montant restant dû au titre de ce retard.
Préférences de messagerie — Dans la fiche lecteur de l'adhérent et dans son compte à l'OPAC, le tableau des préférences de messagerie indique, pour chaque événement, par quel moyen l'adhérent veut être prévenu : courriel, SMS, téléphone, etc. Les événements y apparaissaient dans l'ordre où ils avaient été ajoutés à Koha au fil des versions, sans logique pour l'adhérent : Exemplaire dû, Notification préalable, Réservation remplie, Exemplaire retourné, puis seulement Exemplaire prêté, etc. Ils sont désormais regroupés par thème et présentés à peu près dans l'ordre où ils surviennent : réservations, rappels, PEB, puis le cycle du prêt (Exemplaire prêté, Renouvellement automatique, Notification préalable, Exemplaire dû, Exemplaire retourné).
SMS — La nouvelle préférence système SMSSendMaxChar limite la longueur des SMS.
Transfert d'une liste — Une liste peut changer de propriétaire : le personnel peut la transférer à un autre adhérent depuis le module Listes. Koha transfère aussi automatiquement les listes d'un adhérent supprimé (préférence ListOwnershipUponPatronDeletion). Le nouveau propriétaire n'en était pas informé. Il reçoit désormais un courriel, la notification TRANSFER_OWNERSHIP du nouveau module Listes, qui lui indique le nom de la liste.
Attribution d'un problème de catalogage — Avec les préférences CatalogConcerns et OpacCatalogConcerns, le personnel et les adhérents peuvent signaler un problème sur une notice : erreur, information manquante, etc. Ces signalements se gèrent dans Catalogage › Problèmes de catalogage, où l'on peut confier chacun à un membre du personnel. La personne désignée reçoit désormais un courriel, la notification TICKET_ASSIGNED, avec un lien vers la notice et vers la page de gestion des signalements. Aucun courriel n'est envoyé si l'on s'attribue un signalement à soi-même.

Interface professionnelle

Mémorisation de l'état des tableaux 🆕 — Deux nouvelles options du paramétrage des tableaux font que Koha retient, pendant la session, l'état d'un tableau quand on change de page : colonnes affichées, nombre de lignes et tri d'une part, recherche et filtres d'autre part. Un bouton Copier le lien partageable copie un lien qui restitue l'état du tableau, à garder en favori ou à envoyer à un collègue. Le même bouton existe pour les résultats de la recherche d'exemplaires.
Copie des permissions — Les droits d'un membre du personnel se règlent sur la page Définir les permissions de sa fiche lecteur, en cochant une à une des dizaines de cases. Donner à un nouveau collègue les mêmes droits qu'un autre était long et source d'erreurs. Sur cette page, un bouton Copier les permissions mémorise désormais toutes les cases cochées. Sur la page des permissions d'un autre membre du personnel, le bouton Coller les permissions coche les mêmes cases ; il reste à enregistrer. Les permissions copiées sont gardées dans le navigateur jusqu'à la déconnexion, ou jusqu'à un clic sur Oublier les permissions copiées : on peut donc les coller dans plusieurs fiches lecteur à la suite.
Bootstrap 5 — L'OPAC et l'interface professionnelle reposent sur Bootstrap, une bibliothèque de mise en page : grille, boutons, onglets, fenêtres, menus déroulants, etc. Koha passe de Bootstrap 4, qui n'est plus maintenu, à Bootstrap 5. Les pages de Koha ont été entièrement adaptées, mais pas les personnalisations propres à chaque bibliothèque : feuilles de style et JavaScript des préférences OPACUserCSS, OPACUserJS, IntranetUserCSS et IntranetUserJS, contenu HTML des personnalisations HTML et des actualités. Avant la mise à jour, il faut y rechercher :
- les attributs data-toggle, data-target, data-dismiss, etc., qui deviennent data-bs-toggle, data-bs-target, data-bs-dismiss. Sans cela, un onglet, un bloc dépliable ou une fenêtre ajouté dans une actualité ne réagit plus au clic ;
- les classes supprimées ou renommées par Bootstrap 5, qui n'ont plus d'effet : ml-* et mr-* (devenues ms-* et me-*), float-left et float-right (float-start, float-end), text-left et text-right, badge-* (bg-*), sr-only (visually-hidden), form-group, custom-select (form-select), btn-block. Attention à sr-only : un texte destiné aux seuls lecteurs d'écran devient visible ;
- les sélecteurs CSS ou JavaScript qui visent la structure des pages de Koha (barre de navigation, formulaires, tableaux), dont le balisage a changé.
Les appels JavaScript du type $('#fenetre').modal('show') continuent de fonctionner, car Koha charge jQuery avant Bootstrap.
Page d'accueil — La préférence système IntranetmainUserblock devient une personnalisation HTML, qui peut varier selon la langue et le site.
Commentaires des adhérents — Quand la préférence système OPACComments est activée, les adhérents peuvent commenter une notice à l'OPAC. Les commentaires ne sont publiés qu'après validation par le personnel, dans Outils › Commentaires, qui les présente tous ensemble, sans rapport avec la notice consultée. Dans l'interface professionnelle, la page de détail d'une notice a désormais un onglet Commentaires, avec le nombre de commentaires. Il liste tous les commentaires de la notice, validés ou non, avec leur auteur et leur date. Le personnel qui a la permission de modérer les commentaires peut les valider, les invalider ou les supprimer directement depuis cet onglet.
Langues — La préférence système language est renommée StaffInterfaceLanguages.
Pertes — Les préférences système relatives aux exemplaires perdus sont regroupées dans une nouvelle section Politique des exemplaires perdus.
Tâches de fond sans RabbitMQ — Les traitements longs, comme une modification de notices par lot, un import ou l'indexation Elasticsearch, sont confiés à des tâches de fond : Koha les enregistre dans la base de données, puis un processus séparé, le worker, les exécute. Pour que le worker sache qu'une nouvelle tâche l'attend, Koha le prévient par l'intermédiaire de RabbitMQ, un serveur de messages qu'il faut installer et faire fonctionner à côté de Koha (protocole STOMP). Si RabbitMQ ne répond pas, le worker se rabat sur une interrogation régulière de la base, mais en remplissant les journaux d'avertissements. Beaucoup de bibliothèques, surtout petites, fonctionnent pourtant sans RabbitMQ. La nouvelle préférence système JobsNotificationMethod rend ce choix explicite :
- STOMP (valeur par défaut) : Koha utilise RabbitMQ, comme avant ;
- polling : Koha n'essaie plus de joindre RabbitMQ. Le worker consulte la base de données toutes les dix secondes pour y trouver les nouvelles tâches. Une tâche peut donc démarrer avec quelques secondes de retard, ce qui est sans conséquence pour des traitements de ce type.
Champs supplémentaires 🆕 — Un champ supplémentaire peut être répétable. Les licences, contrats et bouquets de l'ERM acceptent des champs supplémentaires.

Recherche

Renvois « voir aussi » — Avec la nouvelle préférence système IncludeSeeAlsoFromInSearches, une recherche bibliographique trouve aussi les notices liées à une autorité par les formes « voir aussi » (5XX) de cette autorité. Une réindexation est nécessaire.
ISBN et ISSN annulés ou erronés — Avec Elasticsearch, la nouvelle préférence système SearchCancelledAndInvalidISBNandISSN étend la recherche par ISBN ou ISSN aux numéros annulés ou erronés. Un nouvel index, issn-all, regroupe tous les ISSN d'une ressource, ce qui permet de trouver d'un coup les versions imprimée et en ligne d'une revue. En UNIMARC, il contient les 011$a, $y et $z. L'index issn ne garde que le 011$a.
Parcours des cotes — Le parcours des index de la recherche avancée porte aussi sur les cotes.
Recherche d'exemplaires — Le tableau des résultats est configurable.
Disponibilité des exemplaires dans le serveur Z39.50 — Koha peut faire office de serveur Z39.50 (script misc/z3950_responder.pl), que d'autres logiciels interrogent pour récupérer ses notices : catalogue collectif, logiciel de PEB, autre bibliothèque. Lancé avec l'option --add-item-status, ce serveur ajoute à chaque exemplaire renvoyé (995 en UNIMARC, 952 en MARC21) un statut qui dit s'il est disponible ou non : en prêt, perdu, exclu du prêt, endommagé, retiré, en transit, réservé. Le libellé de ces statuts se règle dans la catégorie de valeurs autorisées Z3950_STATUS. Un exemplaire qui ne correspond à aucun de ces cas est déclaré disponible, même s'il ne se prête pas en pratique, par exemple un ouvrage de référence ou un document d'archives. La nouvelle préférence système z3950Status permet d'ajouter ses propres règles d'indisponibilité, sur n'importe quelle colonne de la table items. Par exemple, pour déclarer indisponibles les collections Référence et Archives ainsi que tous les exemplaires présents dans le site REPARATION :
```
ccode: [REF, ARC]
holdingbranch: [REPARATION]
```
Il suffit qu'un exemplaire réponde à l'une des règles.

Rapports

Limites à l'export des rapports — Le résultat d'un rapport SQL peut être téléchargé en CSV, en texte tabulé ou au format ODS (LibreOffice Calc). Koha construit le fichier en mémoire avant de l'envoyer, quel que soit le nombre de lignes. Sur un très gros résultat, par exemple tous les prêts de plusieurs années, le serveur peut manquer de mémoire : l'export échoue au bout d'un long moment et ralentit, voire bloque, les autres services de Koha. La génération d'un fichier ODS est de loin la plus gourmande et peut à elle seule épuiser la mémoire du serveur. Deux nouvelles préférences système permettent de s'en protéger :
- ReportsExportLimit fixe un nombre maximal de lignes exportées. Koha ajoute alors une clause LIMIT à la requête, sauf si le rapport en contient déjà une. L'affichage à l'écran et l'export depuis le tableau (bouton d'export des tableaux) ne sont pas concernés.
- ReportsExportFormatODS permet de retirer l'export ODS du menu de téléchargement. Les exports CSV et texte tabulé restent disponibles.
Mots de passe — Un rapport SQL qui renvoie le mot de passe chiffré des adhérents ne peut plus être exécuté.
Rapports au format JSON : paramètres répétés — Un rapport SQL enregistré peut être interrogé par un programme, qui en reçoit le résultat au format JSON : /cgi-bin/koha/svc/report?id=12 dans l'interface professionnelle, ou à l'OPAC pour un rapport déclaré public. C'est ainsi qu'on alimente, par exemple, un tableau de bord ou une page du site web de la bibliothèque. Les paramètres du rapport sont passés dans l'ordre, avec sql_params. Un même paramètre peut figurer plusieurs fois dans la requête, par exemple un site utilisé à la fois dans une sous-requête et dans la requête principale :
```
SELECT ... WHERE homebranch = <<Site|branches>>
  AND itemnumber NOT IN (SELECT itemnumber FROM issues
                         WHERE branchcode = <<Site|branches>>)
```
Le formulaire de Koha ne demande ce site qu'une fois. L'appel JSON, lui, exigeait de l'envoyer autant de fois qu'il apparaît (&sql_params=CENTRE&sql_params=CENTRE). Il se comporte désormais comme le formulaire : chaque paramètre distinct n'est envoyé qu'une fois, dans l'ordre de sa première apparition (&sql_params=CENTRE). Attention : les scripts qui envoyaient le paramètre plusieurs fois doivent être adaptés.

SIP2

Prêt d'un exemplaire déjà prêté — Avec la nouvelle préférence système AllowItemsOnLoanCheckoutSIP, un automate de prêt peut prêter un exemplaire que Koha considère encore en prêt à un autre adhérent, par exemple parce que son retour n'a pas été enregistré.

Scripts en ligne de commande

automatic_renewals.pl — Les renouvellements automatiques peuvent être traités en parallèle, ce qui accélère beaucoup le script.
longoverdue.pl — Les options --library et --skip-library permettent des règles différentes selon les sites.
sftp_file.pl — Ce nouveau script envoie un fichier sur un serveur SFTP, par exemple un export MARC à destination d'un catalogue collectif.
export_records.pl — L'option --report_id exporte les notices renvoyées par un rapport SQL.
fix_invalid_dates.pl — Dans une base Koha ancienne, ou issue de la migration d'un autre logiciel, certaines dates absentes ont été enregistrées sous la forme 0000-00-00 au lieu d'être laissées vides (NULL) : une date de naissance inconnue, une date d'expiration jamais saisie, etc. MySQL et MariaDB l'acceptaient autrefois, mais cette valeur n'est pas une date valide et provoque aujourd'hui des erreurs : la recherche d'adhérents ou son autocomplétion échoue, le tableau des exemplaires d'une notice ne s'affiche pas, l'API REST renvoie une erreur. Le script misc/maintenance/search_for_data_inconsistencies.pl signale désormais ces dates. Le nouveau script misc/maintenance/fix_invalid_dates.pl les corrige : il parcourt toutes les colonnes de type date de toutes les tables et remplace 0000-00-00 par une valeur vide. Sans l'option --confirm, il ne modifie rien ; avec -v, il affiche le nombre de dates à corriger, colonne par colonne :
```
fix_invalid_dates.pl -v            # simulation
fix_invalid_dates.pl -v --confirm  # correction
```
plugins_nightly.pl — Un plugin peut avoir une tâche à exécuter chaque nuit : synchronisation avec un service externe, envoi de statistiques, nettoyage, etc. Il la déclare au moyen du hook de plugin cronjob_nightly. Le script misc/cronjobs/plugins_nightly.pl, lancé chaque nuit par la crontab quotidienne de Koha, exécute ces tâches pour tous les plugins actifs, l'un après l'autre, à la même heure. Impossible donc de lancer la tâche d'un seul plugin, par exemple à un autre moment ou plus souvent. L'option --metadata (ou -m), répétable, limite désormais le script aux plugins dont les métadonnées correspondent. Par exemple, pour ne lancer que la tâche d'un plugin donné :
```
plugins_nightly.pl -m name="Nom du plugin"
```
Toutes les métadonnées déclarées par le plugin peuvent servir de filtre (name, author, version…). Si l'on en donne plusieurs, le plugin doit les vérifier toutes. Il n'existe pas d'option inverse : le lancement nocturne habituel, sans filtre, exécute toujours la tâche de tous les plugins, y compris celui qu'on lance à part.

API REST

Listes publiques 🆕 — De nouveaux points d'accès publics donnent accès aux listes publiques.
Prêts — Un prêt peut être fait à partir du code à barres de l'exemplaire.
Nouveaux points d'accès — Paniers, règles de circulation, bureaux et caisses d'un site, définitions des champs supplémentaires, rotation des collections. Les dates et le motif d'annulation d'une réservation peuvent être modifiés.

Préférences système

Nouvelles préférences :

AllowItemsOnLoanCheckoutSIP
AlwaysLoadCheckoutsTable
AuthorityXSLTDetailsDisplay
ForcePasswordResetWhenSetByStaff
HoldsQueueParallelLoopsCount
IncludeSeeAlsoFromInSearches
JobsNotificationMethod
MarcOrderingAutomation
NoRefundOnLostFinesPaidAge
OAI-PMH:HarvestEmailReport
OPACItemLocation (anciennement OpacItemLocation)
OPACLoginLabelTextContent
OPACOverDrive
OPACShowLibraries
OPACVirtualCard
OPACVirtualCardBarcode
OpacMetaRobots
ReportsExportFormatODS
ReportsExportLimit
RestrictPatronsWithFailedNotices
SMSSendMaxChar
SearchCancelledAndInvalidISBNandISSN
StaffInterfaceLanguages (anciennement language)
SuggestionsLog
z3950Status

Préférences supprimées :

IntranetmainUserblock (remplacée par une personnalisation HTML)
StaffDetailItemSelection (la sélection des exemplaires est toujours active)