Koha 24.05

mardi 28 mai 2024

Koha 24.05 apporte 8 nouvelles fonctionnalités, 239 améliorations et 529 corrections de bugs. Les prêts à l'heure tiennent compte des heures d'ouverture de la bibliothèque. Une notice peut être verrouillée selon sa provenance. Un nouveau script dédoublonne les autorités, en privilégiant celles qui ont un PPN du Sudoc. Le personnel peut écrire un courriel à un adhérent depuis sa fiche lecteur. Le module ERM importe les fichiers KBART. Avec Elasticsearch, les facettes et les champs de recherche se configurent depuis l'interface professionnelle. Enfin, Koha se protège systématiquement contre les attaques CSRF, ce qui peut demander d'adapter certaines personnalisations.

Circulation

Réservations programmées

La réservation programmée (booking), apparue dans Koha 23.11, porte sur un exemplaire précis et pour une période précise : un vidéoprojecteur pour une soirée, une exposition itinérante pour un mois, etc. Elle s'améliore :

Site de retrait — On choisit le site où l'adhérent retirera l'exemplaire.
Calendrier — Le calendrier marque d'un point bleu les jours où l'exemplaire est déjà réservé.
Fiche lecteur — Les réservations programmées d'un adhérent apparaissent dans sa fiche lecteur.
Confirmation — Un message confirme l'enregistrement d'une réservation programmée.

Prêts à l'heure et heures d'ouverture 🆕

Certaines bibliothèques prêtent pour quelques heures : un ordinateur portable, un manuel très demandé. Avec un prêt de quatre heures consenti à 17 h, le retour tombait à 21 h, bibliothèque fermée. On peut désormais saisir les heures d'ouverture de chaque jour de la semaine dans la fiche du site (Administration › Sites, Heures d'ouverture de la bibliothèque). La nouvelle préférence système ConsiderLibraryHoursInCirculation dit ce que Koha fait quand un prêt à l'heure se termine après la fermeture :

close : le prêt est raccourci, le retour est fixé à l'heure de fermeture ;
open : le prêt est prolongé, le retour est fixé à l'heure d'ouverture du lendemain ;
ignore : les heures d'ouverture ne sont pas prises en compte.

Plus

Réservations en attente au moment du prêt — Avec la nouvelle préférence système WaitingNotifyAtCheckout, une fenêtre avertit le personnel, quand il prête un document à un adhérent, que celui-ci a des réservations qui l'attendent. Il peut ainsi les lui remettre en même temps.
Réclamations de retour résolues automatiquement — Un adhérent affirme avoir rendu un exemplaire que Koha considère toujours en prêt : c'est une réclamation de retour. Quand l'exemplaire réapparaît, il fallait résoudre la réclamation à la main. Les nouvelles préférences système AutoClaimReturnStatusOnCheckin et AutoClaimReturnStatusOnCheckout la résolvent automatiquement quand l'exemplaire est retourné ou prêté de nouveau, avec le motif choisi : Trouvé à la bibliothèque ou Rendu par l'adhérent.
Statut de perte après paiement — Les nouvelles préférences système UpdateItemLostStatusWhenPaid et UpdateItemLostStatusWhenWriteoff changent le statut de perte d'un exemplaire quand ses frais de perte sont payés ou annulés : il passe par exemple de Perdu à Perdu et payé. Les valeurs proposées sont celles de la catégorie de valeurs autorisées LOST.
Usage local — Un exemplaire consulté sur place sans être prêté peut être enregistré comme usage local, en le passant au retour. Ces consultations n'étaient comptées que dans les statistiques. Elles le sont désormais aussi dans l'exemplaire lui-même (items.localuse), comme le nombre de prêts. La colonne Usage local du tableau des exemplaires est masquée par défaut. Le script misc/maintenance/update_localuse_from_statistics.pl calcule ce nombre à partir des statistiques passées.
Bordereaux de transfert — La page Transférer des exemplaires a un bouton pour imprimer le bordereau de transfert.
Réservations à retirer — On peut choisir le tri et le nombre de lignes par défaut des tableaux de cette page.

Réservations

Réservation de plusieurs exemplaires — Avec la nouvelle préférence système DisplayMultiItemHolds, un adhérent peut réserver d'un coup plusieurs exemplaires précis d'une même notice, à l'OPAC comme dans l'interface professionnelle : des cases à cocher remplacent les boutons radio.
Page de réservation — Dans l'interface professionnelle, les trois façons de réserver (prochain exemplaire disponible, prochain exemplaire d'un groupe d'exemplaires, exemplaire précis) sont présentées comme des choix exclusifs, chacun avec ses options.
Réservation des suggestions commandées — Avec la nouvelle préférence système PlaceHoldsOnOrdersFromSuggestions, quand une suggestion acceptée est commandée, Koha réserve automatiquement le document pour l'adhérent qui l'a suggéré. Il est ainsi le premier servi.
Ratio des réservations — Le rapport Circulation › Ratios de réservation repère les documents trop demandés au regard du nombre d'exemplaires possédés. Pour chaque notice, il divise le nombre d'adhérents qui l'ont réservée par le nombre d'exemplaires. Il ne garde que les notices dont le ratio atteint un seuil et indique combien d'exemplaires acheter pour revenir à ce seuil. Avec un seuil de 3, une notice réservée par 10 adhérents et qui a 2 exemplaires (ratio de 5) apparaît avec 2 exemplaires à commander : 10 réservations pour 4 exemplaires donnent un ratio de 2,5. Le rapport est aussi accessible depuis un panier d'acquisition (À partir des titres ayant les plus forts taux de réservations) et chaque ligne permet alors de commander les exemplaires manquants. Le seuil était fixé à 3 et devait être modifié à chaque utilisation du rapport. La nouvelle préférence système HoldRatioDefault permet de choisir le seuil par défaut, adapté à la politique d'achat de la bibliothèque.
File des réservations — La file des réservations indique à chaque site les exemplaires à sortir des rayons pour satisfaire les réservations en attente. Quand plusieurs sites possèdent un exemplaire disponible, Koha doit choisir lequel envoyer à quel adhérent. Avec la préférence système UseTransportCostMatrix, il s'appuie sur la matrice des coûts de transport (Administration › Matrice des coûts de transport), où la bibliothèque note le coût d'un envoi entre chaque paire de sites : distance, fréquence de la navette, etc.

Koha traitait jusqu'ici les réservations d'une notice l'une après l'autre : chacune prenait l'exemplaire le moins coûteux pour elle, au risque de priver la suivante d'un exemplaire bien plus proche. Par exemple, une notice a un exemplaire au site A et un au site B. Le premier adhérent retire au site C, à 1 de A et 2 de B. Le second retire au site A, à 5 de B. Le premier recevait l'exemplaire de A et le second celui de B, pour un coût total de 6. Koha répartit désormais les exemplaires entre toutes les réservations de la notice d'un seul coup, de façon à minimiser le coût total : le premier adhérent reçoit l'exemplaire de B, le second celui de A sur place, pour un coût total de 2.

La matrice, peu lisible quand les sites sont nombreux, garde sa ligne et sa colonne d'en-tête visibles pendant sa modification. La file elle-même a une nouvelle colonne, le site de rattachement de l'exemplaire.

Catalogage

Verrouillage des notices 🆕

Une bibliothèque qui reçoit des notices d'un réservoir externe (un catalogue collectif, une plateforme de ressources électroniques) veut éviter que le personnel les modifie dans Koha : ses modifications seraient écrasées au prochain chargement. Koha connaît désormais la source d'une notice. Les sources se définissent dans Administration › Sources de notices et chacune indique si ses notices peuvent être modifiées. Une notice dont la source l'interdit ne peut plus être modifiée depuis l'interface professionnelle, sauf par le personnel qui a la nouvelle permission edit_locked_records.

Pour l'instant, la source d'une notice ne peut être fixée que par l'API REST ou par un plugin. Il n'est pas encore possible de l'indiquer à la main.

Plus

Avertissement sur le contenu en UNIMARC — La préférence système ContentWarningField désigne une zone de note où l'on signale qu'un document contient des passages sensibles (violence, etc.). Un avertissement s'affiche alors à l'OPAC et dans l'interface professionnelle, sur la page de détail et dans les résultats. Elle était réservée au MARC21. Elle fonctionne maintenant en UNIMARC : on ajoute une zone locale à la grille de catalogage, puis on l'indique dans la préférence. Si la zone a un $u, le $a devient un lien vers cette adresse.
Plugin de recherche d'autorités — Dans la grille de catalogage, une zone liée aux autorités (un auteur en 700, un sujet en 606, etc.) se remplit au moyen d'un plugin : on recherche l'autorité dans une fenêtre, puis on la choisit dans la liste des résultats. Cette liste n'affichait qu'un résumé figé de chaque autorité : sa vedette et ses renvois. Pour des homonymes, par exemple Alexandre Dumas père et fils, il était difficile de choisir la bonne. Les résultats peuvent désormais être mis en forme par une feuille XSLT, celle de la préférence système AuthorityXSLTResultsDisplay, déjà utilisée pour les résultats de la recherche d'autorités. On peut ainsi afficher les dates de l'auteur, sa profession, son PPN ou un lien vers sa notice dans le Sudoc. Le chemin de la feuille peut contenir {langcode} et {authtypecode}, pour avoir une feuille par langue et par type d'autorité. Cela vaut en UNIMARC comme en MARC21.

Deux autres changements dans cette fenêtre :
- le nombre de notices qui utilisent une autorité est un lien vers ces notices, pour vérifier qu'on choisit l'autorité attendue ;
- quand on choisit une vedette proposée par l'autocomplétion, la recherche porte sur cette vedette exacte et ne renvoie plus toutes les autorités qui contiennent ses mots.
Répétition d'une zone à liste déroulante — Dans la grille de catalogage, une sous-zone liée à une catégorie de valeurs autorisées se remplit au moyen d'une liste déroulante : une langue, un code de pays, etc. Quand on répétait cette zone ou cette sous-zone pour en saisir une deuxième occurrence, la copie reprenait la valeur déjà choisie. Pour un document en français et en anglais, la deuxième langue apparaissait ainsi à « français » : il fallait penser à la changer, sinon la notice enregistrait deux fois la même langue. La copie est désormais vide.
Fusion de notices — Les notices sélectionnées pour une fusion sont des liens vers leur page de détail.
Problèmes de catalogage — Un signalement de problème sur une notice peut être confié à un membre du personnel. On peut lui attribuer un statut et un motif de résolution, à définir dans les nouvelles catégories de valeurs autorisées TICKET_STATUS et TICKET_RESOLUTION. La liste des signalements peut masquer ceux qui sont résolus.
MARC21 — La grille de catalogage MARC21 par défaut intègre la mise à jour 37 (décembre 2023), pour les nouvelles installations seulement.

Autorités

Dédoublonnage des autorités 🆕 — Un catalogue alimenté par des imports successifs accumule des autorités en double : plusieurs notices d'autorité pour le même auteur ou le même sujet, chacune liée à une partie des notices bibliographiques. Le nouveau script misc/maintenance/dedup_authorities.pl recherche, pour chaque autorité, les autres autorités du même type qui ont exactement la même vedette. Il en garde une, rattache à elle les notices bibliographiques liées aux autres, puis supprime celles-ci. L'option --method (ou -m), répétable, indique comment choisir l'autorité à garder :
- ppn (UNIMARC seulement) : celle qui a un PPN du Sudoc (zone 009) ;
- date : la plus récemment modifiée (zone 005) ;
- used (par défaut) : la plus utilisée.
Par exemple, -m ppn -m date -m used garde de préférence une autorité du Sudoc, la plus récente parmi elles, puis la plus utilisée en cas d'égalité. L'option --authtypecode (ou -a) limite le traitement à un type d'autorité, --where à certaines autorités. Sans --confirm, le script ne modifie rien et se contente d'annoncer ce qu'il ferait (avec -v -v).
Notes dans les résultats — Les notes des autorités sont affichées dans une fenêtre, depuis les résultats de recherche d'autorités.
Prévisualisation — Une autorité en cours de modification peut être prévisualisée au format MARC.

Acquisitions

Lignes de commande annulées — Elles peuvent être supprimées d'un panier ouvert.
Notices supprimées — Le résumé d'un panier affiche le titre d'une notice supprimée depuis la commande.
Messages EDIFACT — Le tableau des messages est bien plus rapide quand ils sont nombreux.
Comptes EDI — On peut indiquer un port SFTP autre que 22.
Commande à partir d'un fichier MARC — La préférence système MarcItemFieldsToOrder peut renseigner le code à barres, le numéro de volume (enumchron) et le coded_location_qualifier des exemplaires.
Bon de commande PDF — La nouvelle préférence système 1PageOrderPDFText remplace la phrase imprimée au-dessus du tableau dans le bon de commande PDF anglais d'une page.

Périodiques

Numérotation par la date — Le modèle de numérotation d'un abonnement peut utiliser la date de parution du numéro : {Year}, {Month}, {MonthName}, {Day}, {DayName}. Le nom du mois et du jour est donné en anglais.
Numéros doubles — Quand un éditeur publie un numéro double, le bouton Ignorer le fascicule et générer le suivant de la page de collection saute les numéros qui ne paraîtront pas.
Listes de circulation — La recherche avancée d'abonnements peut se limiter aux abonnements qui ont une liste de circulation.

ERM

Import de fichiers KBART 🆕 — Les éditeurs et les agrégateurs décrivent le contenu de leurs bouquets de ressources électroniques dans des fichiers KBART, un format normalisé. Un bouquet local peut désormais être alimenté par l'import d'un tel fichier (Importer à partir d'un fichier KBART), au lieu de saisir ses titres un par un. On peut aussi créer, en même temps, une notice bibliographique pour chaque titre.
Notices bibliographiques facultatives — Dans le module ERM, un bouquet local regroupe des titres (revues, livres électroniques) saisis par la bibliothèque. Chaque titre créé produisait automatiquement une notice bibliographique dans le catalogue, pour qu'on puisse le trouver par la recherche. Cette notice est minimale : elle ne contient que le titre. Une bibliothèque qui catalogue déjà ses ressources électroniques, par exemple en important les notices du Sudoc, se retrouvait avec des doublons pauvres. C'est encore plus gênant lors d'un import KBART, qui peut créer des milliers de titres. Une case à cocher, Création de la notice bibliographique liée, décide désormais si la notice est créée, à la saisie d'un titre comme à l'import d'un fichier KBART.

Adhérents

Courriel à un adhérent 🆕 — Le personnel qui a la permission send_messages_to_borrowers peut envoyer un courriel à un adhérent depuis sa fiche lecteur : le bouton Ajouter un message propose un nouveau type, Email. Le message peut partir d'un modèle, à créer dans le nouveau module de notifications Adhérents (message personnalisé). Par exemple, un modèle pour rappeler à un adhérent de mettre à jour ses coordonnées.
Types de restriction — Le type et la date d'expiration des restrictions sont affichés sur la page de prêt, dans la fiche lecteur de l'adhérent et à l'OPAC, une restriction par ligne. Seul le commentaire était affiché. L'ajout, la modification et la levée d'une restriction sont journalisés (préférence système BorrowersLog).
Attributs de type date — Un attribut d'adhérent peut être une date, saisie avec le calendrier.
Saisie des dates — Une date peut être saisie sans séparateur, par exemple 28052024 pour le 28/05/2024.
Garants — Quand on ajoute un garant à un adhérent existant, ses coordonnées peuvent être reprises.
Adhérents protégés — Une icône signale les adhérents protégés contre la suppression.
Recherche d'adhérents — La liste proposée dès les premières lettres saisies (PatronAutoComplete) affiche aussi les autres noms de l'adhérent. Les recherches d'adhérents qui ouvraient une fenêtre de navigateur (liste de circulation d'un périodique, gestionnaire d'une suggestion, garant) s'ouvrent dans une fenêtre de la page.

Notifications

Plusieurs adresses électroniques — Un adhérent peut avoir trois adresses électroniques : principale, secondaire et de secours. Koha n'écrivait qu'à l'une d'elles. Quand la préférence système EmailFieldPrimary vaut adresses sélectionnées, il écrit à toutes celles qui sont cochées dans la nouvelle préférence EmailFieldSelection.
Mise en forme à l'impression — Koha imprime des tickets à la banque de prêt : ticket de prêt, de retour, de réservation, de transfert, reçu de paiement, etc. Leur contenu se rédige dans l'éditeur de notifications, mais leur apparence ne pouvait être réglée que globalement, par une feuille de style unique pour tous les tickets, à déposer sur un serveur web et à désigner par son adresse dans la préférence système SlipCSS. Chaque notification a désormais une section Format, avec un champ Style (CSS) qui s'applique quand elle est imprimée. On peut ainsi agrandir le titre d'un ticket de réservation, réduire les marges d'un ticket de prêt pour une imprimante thermique étroite ou encadrer le tableau d'un reçu, sans toucher aux autres tickets. Trois liens, Vedettes, Tableaux et Tout le texte, insèrent dans le champ les sélecteurs CSS correspondants : il ne reste qu'à compléter les propriétés, par exemple :
```
h1, h2, h3, h4, h5, h6 { font-size: 14pt; }
table { border-collapse: collapse; }
```
Le style est propre à chaque langue de la notification. Il s'applique aux tickets de prêt (ISSUESLIP, ISSUEQSLIP), de retour (CHECKINSLIP), de réservation (HOLD_SLIP), de transfert (TRANSFERSLIP), de retards (OVERDUES_SLIP), de demande d'article (AR_SLIP), de rappel (RECALL_REQUESTER_DET), ainsi qu'aux reçus et relevés de compte (RECEIPT, ACCOUNT_CREDIT, ACCOUNT_DEBIT, ACCOUNTS_SUMMARY).
Expéditeur et destinataires — Dans l'onglet Notifications de la fiche lecteur d'un adhérent, chaque notification envoyée indique son expéditeur et ses destinataires.
En-têtes des courriels — Les courriels envoyés par Koha contiennent deux en-têtes, X-Koha-Template-ID et X-Koha-Message-ID, qui identifient le modèle et le message. Ils aident à retrouver l'origine d'un courriel problématique.
Bienvenue — La notification WELCOME est imprimée si l'adhérent n'a pas d'adresse électronique.
Template Toolkit — Plusieurs notifications par défaut sont réécrites avec Template Toolkit : PREDUE, DUE, RENEWAL, HOLD, HOLD_SLIP, TO_PROCESS, AVAILABLE et celles des suggestions. Cela ne change rien aux notifications existantes, qui ne sont pas remplacées.
Options du pilote SMS — Koha envoie ses SMS par l'intermédiaire d'un prestataire, au moyen d'un pilote, un module Perl SMS::Send propre à ce prestataire, désigné par la préférence système SMSSendDriver. Les préférences SMSSendUsername et SMSSendPassword lui transmettent l'identifiant et le mot de passe du compte. Certains pilotes demandent d'autres paramètres : le nom de l'expéditeur affiché sur le téléphone, l'adresse du service, une clé d'API, etc. Il fallait les écrire dans un fichier YAML sur le serveur, dans le répertoire indiqué par sms_send_config dans koha-conf.xml, ce qui demandait l'intervention de l'administrateur du serveur. La nouvelle préférence système SMSSendAdditionalOptions permet de les saisir, toujours en YAML, directement dans l'interface professionnelle. Le fichier reste lu : en cas de conflit, la valeur de la préférence l'emporte.

OPAC

Informations sur l'auteur — La nouvelle préférence système OPACAuthorIdentifiersAndInformation affiche, sur la page de détail d'une notice (onglet Informations sur l'auteur) et sur celle d'une autorité, des informations tirées de l'autorité : identifiants (ORCID, VIAF, etc.), domaine d'activité, profession, lieux de naissance et de décès, adresse, etc. Elle remplace OPACAuthorIdentifiers. MARC21 seulement : les zones lues (024, 370 à 374) n'existent pas en UNIMARC : Koha n'affiche rien pour une installation UNIMARC.
Résultat unique — Quand une recherche ne trouve qu'une notice, Koha ouvre directement sa page de détail. La nouvelle préférence système RedirectToSoleResult permet d'afficher à la place la liste de résultats, avec cette seule notice. C'est aussi valable dans l'interface professionnelle.
Adresse canonique — Les pages de détail indiquent leur adresse canonique aux moteurs de recherche. Une même notice n'est plus indexée plusieurs fois sous des adresses différentes.
Consentement aux cookies — Avec la préférence système CookieConsent, un bandeau en bas des pages de l'OPAC et de l'interface professionnelle demande au visiteur son consentement aux cookies, comme l'exige le RGPD. La bibliothèque peut déclarer, dans la préférence CookieConsentedJS, des scripts de suivi qui ne s'exécutent qu'après consentement, par exemple les statistiques de fréquentation Matomo. Les cookies essentiels, eux, sont indispensables au fonctionnement de Koha : celui de la session de l'utilisateur connecté, par exemple. Si aucun script de suivi n'était déclaré, le bandeau n'offrait qu'un bouton Accepter tous les cookies, trompeur puisqu'il n'y avait rien d'autre à accepter que les cookies essentiels. Aucun bouton ne permettait d'en savoir plus. Désormais, le bouton Accepter les cookies essentiels est toujours présent et Accepter tous les cookies n'apparaît que si des scripts de suivi sont déclarés. Le bouton Plus d'informations est lui aussi toujours affiché : il ouvre une fenêtre dont le texte se rédige dans la personnalisation HTML CookieConsentPopup. Les nouvelles installations qui chargent les actualités d'exemple reçoivent un texte par défaut, qui décrit les cookies utilisés par Koha.
Notes — Chaque note de la page de détail a un identifiant et des classes propres, par exemple marcnote marcnote-300, pour les mettre en forme dans OPACUserCSS.
Historique des réservations — Le motif d'annulation est affiché.
Périodiques — La préférence système opacSerialDefaultTab peut ouvrir par défaut l'onglet des informations sur le titre.

Prêt en libre-service

Prêt par lot à l'automate 🆕 — L'automate de prêt de Koha (module SCO) peut prêter plusieurs exemplaires d'un coup : l'adhérent scanne tous ses codes à barres, puis valide. La nouvelle préférence système SCOBatchCheckoutsValidCategories indique les catégories d'adhérents autorisées. Les exemplaires sont traités dans l'ordre : si l'un d'eux demande une confirmation ou ne peut pas être prêté, le traitement s'arrête là et les exemplaires suivants ne sont pas prêtés.

Interface professionnelle

Tableau des exemplaires — Le tableau des exemplaires de la page de détail d'une notice est entièrement réécrit. Le tri, le filtrage et la pagination se font par l'API REST : une notice de plusieurs centaines d'exemplaires, par exemple un périodique, s'affiche bien plus vite.
Copie des permissions — Les permissions d'un membre du personnel peuvent être copiées vers un autre.
Choix du site — Le menu de l'utilisateur, en haut à droite, permet de changer de site, de bureau et de caisse.
Connexion selon l'adresse IP — Chaque site peut avoir une plage d'adresses IP. La préférence système AutoLocation est remplacée par deux nouvelles préférences. StaffLoginLibraryBasedOnIP fixe le site de connexion d'après l'adresse IP de l'ordinateur. StaffLoginRestrictLibraryByIP limite les sites qu'on peut choisir à la connexion à ceux dont la plage contient cette adresse.
Retour en haut — Un bouton ramène en haut de la page, comme à l'OPAC.
Statuts des exemplaires — Dans l'interface professionnelle, la colonne Statut du tableau des exemplaires d'une notice indique la situation de chaque exemplaire. Un même exemplaire peut cumuler plusieurs statuts : en prêt et endommagé, en transit et réservé, exclu du prêt et retiré, etc. Ces statuts s'affichaient à la suite, en une seule ligne, si bien qu'on distinguait mal où finissait l'un et où commençait l'autre. Chacun a désormais sa propre ligne dans la cellule.
Transferts à envoyer — Ce lien de la page d'accueil de la circulation n'est affiché que si la rotation des collections est activée (StockRotation).

Recherche

Elasticsearch

Facettes configurables 🆕 — Les facettes affichées à gauche des résultats (auteurs, sujets, sites, etc.) étaient fixées dans le code de Koha. Elles se configurent désormais dans Administration › Configuration du moteur de recherche (Elasticsearch) : tout champ de recherche marqué Facettable et Interrogeable peut servir de facette. Une facette peut être liée à une catégorie de valeurs autorisées, pour afficher le libellé au lieu du code. Par exemple, le type de ressource enregistré dans une zone locale 9XX.
Champs de recherche — On peut ajouter des champs de recherche depuis la même page. Il fallait jusqu'ici modifier un fichier YAML sur le serveur.
Troncature automatique — Avec la préférence système QueryAutoTruncate, Koha ajoute une troncature à la fin de chaque terme recherché : hist trouve histoire et historique. Pour un identifiant, c'est gênant : la recherche du code à barres 1234 trouvait aussi 12345. La nouvelle préférence système ESPreventAutoTruncate liste les index exclus de la troncature automatique, par défaut les codes à barres, les ISBN, les ISSN et autres identifiants. Elle est renommée ElasticsearchPreventAutoTruncate dans Koha 25.11.
Lieu de publication — L'index pl inclut, en UNIMARC, les 210$a et 214$a.
ISBN annulés ou erronés — Un nouvel index, isbn-all, contient les ISBN valides, annulés et erronés.
Réindexation partielle — L'option --where du script rebuild_elasticsearch.pl choisit par une condition SQL les notices à réindexer, par exemple --where "biblionumber > 100000".
Recherche géographique 🆕 — Certaines notices décrivent des documents liés à un lieu précis : une carte, une photographie aérienne, une étude géologique, les relevés d'une station météorologique. Leur notice peut contenir les coordonnées de ce lieu, en latitude et en longitude. Elasticsearch sait les indexer comme un point géographique, puis trouver les notices situées à moins d'une certaine distance d'un point donné, par exemple tous les documents à moins de 10 km de Grenoble. Koha prépare désormais cette recherche : un nouveau type de champ de recherche, geo_point, réunit latitude et longitude dans l'index geolocation. Le moteur de recherche de Koha accepte aussi une requête par distance. Koha n'offre pas lui-même d'écran pour cette recherche : il faut installer le plugin HKS3GeoSearch, qui ajoute à l'OPAC une carte sur laquelle on désigne le lieu. La correspondance par défaut lit les 034$s et $t, en MARC21 seulement. En UNIMARC, rien n'est prévu : il faut ajouter soi-même la correspondance dans la configuration du moteur de recherche. Cette fonctionnalité nécessite Elasticsearch 7 ou plus récent.

Plus

Recherche d'exemplaires — Les listes à choix multiples (sites, types de document, etc.) se remplissent en tapant les premières lettres, sans maintenir la touche Ctrl. Les résultats affichent le numéro d'exemplaire et la date du dernier prêt.
Zebra — Sans ICU, ÿ est recherché comme y.

Rapports

Paramètres à choix multiple — Un paramètre de rapport lié à une liste de valeurs autorisées peut accepter plusieurs valeurs, avec le suffixe :in. Par exemple, pour les exemplaires de plusieurs sites choisis à l'exécution :
```
SELECT barcode FROM items WHERE homebranch IN <<Sites|branches:in>>
```
Le suffixe :all ajoute à la liste une option pour choisir toutes les valeurs. La fenêtre d'insertion d'un paramètre propose ces deux choix.
Export CSV — Le code HTML d'un rapport (des liens, par exemple) est retiré de l'export CSV. Le nom du fichier exporté contient le numéro du rapport.

Plugins

Installation sans redémarrage — Un plugin installé ou mis à jour depuis l'interface professionnelle est actif sans demander à l'administrateur du serveur de redémarrer Koha (option plugins_restart de koha-conf.xml, activée par défaut dans les nouvelles installations).
Plugins d'administration — Un plugin peut offrir au personnel une ou plusieurs pages de travail. Jusqu'ici, il en existait deux types : les plugins d'outils, rangés dans le module Outils ; les plugins de rapports, rangés dans le module Rapports. Un plugin qui sert à paramétrer Koha ou à le relier à un service externe n'avait pas de place logique : il fallait passer par la page de gestion des plugins ou le déguiser en outil. Un troisième type apparaît, le plugin d'administration. Il est listé dans la section Plugins de la page d'accueil du module Administration, avec son nom et sa description. Son accès est contrôlé par une nouvelle permission, admin dans la catégorie plugins, qui suffit à elle seule à faire apparaître le module Administration. On peut ainsi confier un plugin d'administration à un membre du personnel sans lui donner accès au reste du paramétrage de Koha. Pour le développeur, il suffit que le plugin fournisse une méthode admin.
Nouveaux hooks de plugin — before_biblio_action modifie une notice juste avant son enregistrement, par exemple pour calculer une zone à partir d'autres. auth_client_get_user modifie ou choisit l'adhérent après une authentification externe (OAuth, OpenID Connect). D'autres hooks portent sur les notifications et le tableau des demandes de PEB.
PEB — Un backend de PEB peut être fourni par un plugin Koha ordinaire.

Sécurité

Protection CSRF — Une attaque CSRF fait exécuter à Koha, à l'insu d'un membre du personnel connecté, une action qu'il n'a pas voulue : par exemple, un lien piégé reçu par courriel qui supprime une notice. Koha vérifie désormais que chaque formulaire qui modifie des données a bien été produit par Koha lui-même : il contient un jeton secret (csrf_token) et son paramètre op commence par cud-. Les modifications ne se font plus par simple lien (requête GET).

Attention aux personnalisations qui envoient des formulaires ou appellent les services /cgi-bin/koha/svc/ : JavaScript des préférences IntranetUserJS et OPACUserJS, plugins, outils externes. Elles doivent être adaptées, sinon Koha rejette leurs requêtes. Les services svc fournissent un jeton par /cgi-bin/koha/svc/authentication.

Scripts en ligne de commande

export_records.pl — L'option --embed_see_from_headings ajoute aux notices exportées les formes rejetées des autorités liées. Un moteur de recherche externe peut ainsi trouver une notice par une forme rejetée.
pseudonymize_statistics.pl — Pour produire des statistiques sur l'usage de la bibliothèque sans conserver l'identité des adhérents, Koha propose la pseudonymisation (préférence système Pseudonymization). Chaque prêt, renouvellement, retour ou prêt sur place est alors copié dans une table à part, pseudonymized_transactions. L'adhérent y est remplacé par un code obtenu par hachage, toujours le même pour un même adhérent, mais qui ne permet pas de retrouver qui il est. On y garde seulement les informations utiles aux statistiques, choisies dans les préférences PseudonymizationPatronFields (catégorie, site, ville, sexe, etc.) et PseudonymizationTransactionFields (date, site, type de document, collection, etc.). On peut ainsi compter les lecteurs distincts ou suivre les usages d'une catégorie d'adhérents, même après l'anonymisation de l'historique des prêts. Seules les transactions postérieures à l'activation de la préférence étaient pseudonymisées. Le nouveau script misc/maintenance/pseudonymize_statistics.pl traite après coup les transactions plus anciennes de la table des statistiques, jusqu'à la date donnée par l'option --before (par défaut, jusqu'à maintenant). Sans --confirm, il ne fait rien ; avec -v, il indique combien de transactions il traiterait. Attention : les informations de l'adhérent et de l'exemplaire sont celles d'aujourd'hui, pas celles du jour de la transaction. Pour un adhérent ou un exemplaire supprimé depuis, ces informations sont perdues.
longoverdue.pl — Les nouvelles préférences système DefaultLongOverduePatronCategories et DefaultLongOverdueSkipPatronCategories indiquent les catégories d'adhérents traitées ou ignorées, quand le script est lancé sans les options correspondantes.
cleanup_database.pl — La nouvelle préférence système PurgeListShareInvitesOlderThan fixe le délai au-delà duquel les invitations à partager une liste privée qui n'ont pas été acceptées sont supprimées (14 jours par défaut).
acq_cancel_obsolete_orders.pl — Ce nouveau script annule les lignes de commande en attente dont la notice a été supprimée.
koha-run-backups — Une option exclut les journaux de la sauvegarde.

API REST

Fusion de notices — Une notice peut être fusionnée dans une autre.
Nouveaux points d'accès — Prêts d'un adhérent, catégories d'adhérents, notices supprimées, historique des réservations et rappels d'un adhérent, bureaux et caisses d'un site.
Site de renouvellement — La nouvelle préférence système RESTAPIRenewalBranch indique le site à enregistrer pour un renouvellement fait par l'API, quand la requête ne le précise pas.

Préférences système

Nouvelles préférences :

1PageOrderPDFText
AutoClaimReturnStatusOnCheckin
AutoClaimReturnStatusOnCheckout
ConsiderLibraryHoursInCirculation
DefaultLongOverduePatronCategories
DefaultLongOverdueSkipPatronCategories
DisplayMultiItemHolds
ESPreventAutoTruncate
EmailFieldSelection
HoldRatioDefault
OPACAuthorIdentifiersAndInformation
PlaceHoldsOnOrdersFromSuggestions
PurgeListShareInvitesOlderThan
RESTAPIRenewalBranch
RedirectToSoleResult
SCOBatchCheckoutsValidCategories
SMSSendAdditionalOptions
StaffLoginLibraryBasedOnIP
StaffLoginRestrictLibraryByIP
UpdateItemLostStatusWhenPaid
UpdateItemLostStatusWhenWriteoff
WaitingNotifyAtCheckout

Préférences supprimées :

AutoLocation (remplacée par StaffLoginLibraryBasedOnIP et StaffLoginRestrictLibraryByIP)
ILLModuleCopyrightClearance (remplacée par une personnalisation HTML)
OPACAuthorIdentifiers (remplacée par OPACAuthorIdentifiersAndInformation)