Tamil
Actualité

Koha 25.05

mardi 27 mai 2025
Koha 25.05

Le Printemps est évident, car du cœur des Propriétés vertes, Koha s'avance en 25.05, riche de 5 nouvelles fonctionnalités, 186 améliorations et 481 corrections de bugs. Le module de prêt entre bibliothèques (PEB) progresse nettement : choix automatique du fournisseur, demandes sans connexion à l'OPAC, détection des demandes déjà faites. La gestion des fournisseurs est réécrite, les autorités supprimées sont conservées et les opérations de caisse gagnent en souplesse. Pour l'UNIMARC, on peut choisir la langue de la vedette d'autorité reportée dans la notice bibliographique.

Prêt entre bibliothèques (PEB)

Choix automatique du fournisseur 🆕

Koha peut gérer plusieurs fournisseurs de PEB (backends). Jusqu'ici, la personne qui faisait une demande devait choisir le fournisseur. Désormais, si la préférence système AutoILLBackendPriority est renseignée, le formulaire Standard est toujours affiché et Koha détermine lui-même le fournisseur le plus adapté, selon la disponibilité du document et l'ordre de priorité défini dans la préférence. Dans l'interface professionnelle, un écran de confirmation présente le fournisseur proposé. Un lien Retour au formulaire permet de corriger la demande, par exemple quand la vérification de disponibilité a échoué. Le bouton Changer de fournisseur d'une demande existante interroge, lui aussi, tous les fournisseurs installés et propose le plus approprié.

Seuls les fournisseurs qui savent vérifier la disponibilité d'un document peuvent participer à ce choix automatique.

Demandes sans connexion à l'OPAC 🆕

Avec la nouvelle préférence système ILLOpacUnauthenticatedRequest, un visiteur peut faire une demande de PEB à l'OPAC sans se connecter. C'est utile quand un service externe renvoie l'utilisateur directement vers le formulaire de demande de Koha.

Demandes déjà faites 🆕

Avec la nouvelle préférence système ILLHistoryCheck, une étape supplémentaire vérifie, avant l'envoi d'une demande, si la même demande a déjà été faite par le passé.

Plus

  • Onglets de la liste des demandes — La nouvelle préférence système ILLRequestsTabs ajoute des onglets à la liste des demandes de PEB. Chaque onglet regroupe un ou plusieurs statuts. Par exemple :

    - name: Nouvelles
  status:
    - NEW
- name: Demandées ou annulées
  status:
    - REQ
    - REQREV

    On peut aussi filtrer la liste sur plusieurs statuts à la fois.

  • Demandes de l'OPAC — Le tableau des demandes de l'adhérent, à l'OPAC, est paginé et permet la recherche.

  • Lots — Un lot de demandes peut être modifié sans y ajouter de nouvelle demande.

  • Identifiant PubMed — PubMed est une base de références bibliographiques en médecine et biologie, où chaque article a un identifiant (PMID). Le formulaire de PEB Standard de Koha n'a pas de champ pour cet identifiant, mais un plugin, comme ILL Actions, peut en ajouter un. La valeur saisie dans ce champ était perdue. Elle est désormais enregistrée avec la demande et affichée sur la page de gestion de la demande.

Acquisitions

  • Fournisseurs 🆕 — La gestion des fournisseurs est réécrite en Vue.js, comme le module ERM. La fiche d'un fournisseur affiche le nombre de paniers et d'abonnements qui lui sont rattachés et un fournisseur qui en a ne peut pas être supprimé.

  • Suggestion disponible — Une suggestion qui n'est pas liée à une commande peut être marquée comme disponible depuis la page de gestion des suggestions. La notification AVAILABLE est alors envoyée à l'adhérent.

  • Suggestions plus rapides — Les tableaux des suggestions utilisent l'API REST. Ils s'affichent beaucoup plus vite quand les suggestions sont nombreuses.

  • Erreurs EDIFACT — Les erreurs d'import des messages EDIFACT n'étaient visibles que dans les journaux du serveur. Elles sont désormais consultables dans l'interface professionnelle.

  • Nom du panier dans le fichier MARC — Koha peut créer automatiquement des commandes à partir de fichiers MARC déposés par un fournisseur (préférence système MarcOrderingAutomation). Chaque fournisseur a un compte pour les commandes MARC (Administration › Comptes pour les commandes MARC) qui indique notamment le répertoire où ses fichiers sont déposés. Le script misc/cronjobs/marc_ordering_process.pl, lancé régulièrement, traite chaque nouveau fichier : il importe les notices, crée les exemplaires, puis un panier qui reçoit les lignes de commande. Ce panier prenait jusqu'ici le nom du fichier.

    Certains fournisseurs indiquent dans le fichier MARC lui-même le nom du panier auquel les notices sont destinées. Le compte pour les commandes MARC a un nouveau paramètre, Zone du nom du panier, où l'on indique la sous-zone qui contient ce nom, au format zone$sous-zone (par exemple 971$a), comme dans la préférence MarcFieldsToOrder. Koha lit cette sous-zone dans la première notice du fichier ; les suivantes sont ignorées. Si la sous-zone est absente ou vide, le nom du fichier sert de nom de panier, comme avant. Le nom est tronqué à 50 caractères.

Catalogage

Choix de la langue de la vedette d'autorité (UNIMARC)

Une notice d'autorité UNIMARC peut contenir plusieurs formes de la vedette, dans différentes langues, la langue étant codée en $7. Quand on lie une notice bibliographique à une autorité, Koha reportait la première vedette. Avec la nouvelle préférence système LanguageToUseOnMerge, Koha reporte la vedette dont le $7 contient le code de langue indiqué, si elle existe. Le code peut être court (ba pour le latin) ou long (ba0yba0y).

Plus

  • Ajout d'exemplaires par lot — La modification de notices par lot, combinée aux modèles de modification MARC, peut ajouter des exemplaires à des notices existantes. Il suffit que le modèle ajoute une zone 995 (UNIMARC) ou 952 (MARC21).

  • Autorités supprimées 🆕 — Une nouvelle table deletedauthorities conserve les notices d'autorité supprimées, comme deletedbiblio_metadata le fait pour les notices bibliographiques.

  • Liaison aux autorités — Avec la nouvelle préférence système LinkerConsiderDiacritics, la liaison automatique aux autorités distingue les caractères accentués (A, Å, Ä…). Avec ConsiderHeadingUse, Koha respecte l'usage prévu d'une vedette d'autorité MARC21 (008/14-16 : vedette principale ou secondaire, vedette matière, collection).

  • Dates des exemplaires — Dans le formulaire d'ajout ou de modification d'un exemplaire, une sous-zone liée à une colonne date de la table items affiche automatiquement un calendrier. C'est le cas, par exemple, de la date d'acquisition (dateaccessioned, 995$5 en UNIMARC), de la date de retour prévue (onloan, 995$n) ou de la date de dernier prêt. Pour les dates avec heure (date de perte, de retrait, date à laquelle l'exemplaire a été vu pour la dernière fois, etc.), le calendrier permet aussi de choisir l'heure. Quand la sous-zone est vide, le calendrier s'ouvre sur la date du jour et la saisit. Jusqu'ici, il fallait lier un plugin de catalogage à la sous-zone, comme dateaccessioned.pl. Le calendrier est désormais prioritaire sur ce plugin.

  • Navigation dans les cotes — La fenêtre du plugin de navigation dans les cotes (cn_browser.pl) peut être redimensionnée et Koha retient sa taille.

  • Plugins de catalogage personnalisés — Attention, changement incompatible : le premier paramètre des fonctions JavaScript des plugins de catalogage est toujours un objet Event. L'identifiant HTML de la zone se trouve dans event.data.id.

  • Numéro d'inventaire — La zone numéro d'inventaire (items.stocknumber) passe de 32 à 80 caractères.

  • Stockage des autorités — La table auth_header ne stocke plus la notice d'autorité qu'en MARCXML.

Circulation

  • Frais de réservation non retirée — Les frais appliqués quand une réservation n'est pas retirée à temps peuvent être définis dans les règles de circulation. À défaut, la préférence système ExpireReservesMaxPickUpDelayCharge s'applique.

  • Déjà emprunté ? — La préférence CheckPrevCheckout vérifie aussi les prêts en cours. Si AllowMultipleIssuesOnABiblio permet d'emprunter plusieurs exemplaires d'une même notice, un message demande de confirmer le prêt quand l'adhérent a déjà ce titre en prêt.

  • Page de prêt — Depuis l'accueil du module Circulation, le lien Prêt ouvre la page de prêt sans adhérent sélectionné. Cette page était vide : il fallait passer par le champ de recherche de l'en-tête pour trouver l'adhérent. Elle affiche désormais, au centre de la page, un champ de recherche d'adhérent, par numéro de carte ou partie du nom, avec autocomplétion, comme la page de retour affiche directement son formulaire.

  • Journalisation des transferts — Un exemplaire est transféré d'un site à un autre quand il doit rejoindre son site de rattachement, ou le site de retrait d'une réservation. Le journal des actions enregistrait déjà les réservations et les prêts, mais pas ces transferts : on ne pouvait pas y suivre le parcours complet d'une réservation qui nécessite un transfert. Quand la nouvelle préférence système TransfersLog est activée, chaque étape d'un transfert est journalisée : sa création, puis chacune de ses modifications (envoi, réception, annulation). L'entrée du journal contient toutes les données du transfert : site d'origine, site de destination, dates d'envoi et d'arrivée, motif, etc. Ces entrées sont consultables dans Outils › Journaux, module Transferts.

  • Demandes d'article — Quand la préférence système ArticleRequests est activée, un adhérent peut demander la reproduction d'un article ou d'un chapitre (photocopie, numérisation). Les règles de circulation permettent de limiter le nombre de demandes en cours qu'un adhérent peut avoir : demandes nouvelles, en attente ou en traitement, plus celles terminées le jour même. Cette limite ne pouvait être fixée que catégorie d'adhérent par catégorie. On peut désormais choisir Toutes dans la liste des catégories : la limite s'applique alors à toutes les catégories, sauf à celles qui ont leur propre limite.

Réservations

  • Priorité aux réservations locales — La préférence système LocalHoldsPriority propose maintenant quatre valeurs : priorité au site, au site et à son groupe, au groupe de sites, ou aucune priorité. La file des réservations doit être recalculée après une modification.

  • Historique des réservations — L'historique des réservations d'un adhérent est séparé en deux tableaux, réservations en cours et réservations passées, avec des filtres (toutes, en attente, à retirer, satisfaites).

  • Réservations à retirer — Le tableau affiche le moyen de contact principal de l'adhérent. Après l'annulation d'une réservation, on reste sur le même onglet.

  • Clubs — Sur la page de réservation d'une notice, la recherche de clubs sans critère affiche la liste de tous les clubs.

  • SIP2 — Avec la nouvelle préférence système HoldCancellationRequestSIP, une annulation de réservation faite par SIP2 devient une demande d'annulation, que le personnel valide.

Amendes et frais

  • Notes sur les opérations — On peut ajouter une note à toutes les opérations du compte de l'adhérent : remise, paiement ou annulation d'un frais, remboursement, etc. Ces notes peuvent être modifiées, avec la nouvelle sous-permission edit_notes.

  • Reçu par courriel — Le reçu d'un paiement ou d'une annulation peut être envoyé par courriel à la demande, depuis la ligne de l'opération (Reçu › Courriel). La préférence UseEmailReceipts, qui envoie les reçus automatiquement, est renommée AutomaticEmailReceipts.

  • Champs supplémentaires — Chaque opération du compte d'un adhérent a un type : type de débit (amende de retard, frais de location, exemplaire perdu, vente, etc.) ou type de crédit (paiement, remise, etc.). Une bibliothèque peut définir ses propres types et en avoir beaucoup. Mais son logiciel comptable utilise souvent d'autres codes, moins nombreux : dix types de vente peuvent relever d'un même compte. Rapprocher les deux était fastidieux.

    On peut désormais ajouter des champs supplémentaires aux types de débit et de crédit (Administration › Champs supplémentaires), par exemple un champ Code comptable. Sa valeur se saisit dans le formulaire du type de débit ou de crédit et s'affiche dans la liste des types. Un rapport SQL peut alors totaliser les opérations par code comptable. Par exemple :

    SELECT v.value AS code_comptable, SUM(a.amount) AS total
FROM accountlines a
JOIN additional_field_values v ON v.record_id = a.debit_type_code
JOIN additional_fields f ON f.id = v.field_id
WHERE f.tablename = 'account_debit_types'
  AND f.name = 'Code comptable'
  AND a.date BETWEEN <<Du|date>> AND <<Au|date>>
GROUP BY v.value

  • Calcul des amendes par un plugin — Koha calcule le montant d'une amende de retard selon les règles de circulation : montant par jour ou par heure, délai de grâce, plafond, etc. Ce calcul a lieu chaque nuit avec le script fines.pl et au retour de l'exemplaire. Certaines bibliothèques ont des règles qu'il ne permet pas d'exprimer, par exemple une amende forfaitaire qui augmente à chaque lettre de rappel.

    Un nouveau hook de plugin, overwrite_calc_fine, permet à un plugin de remplacer ce calcul. À chaque calcul, Koha appelle le plugin en lui transmettant l'exemplaire, l'adhérent, sa catégorie, le site, la date de retour prévue et la date de fin du calcul. Le plugin renvoie le montant de l'amende, ou rien : Koha applique alors son calcul habituel. Le plugin peut ainsi ne traiter que certains cas. Quand un tel plugin est actif, la page des règles de circulation affiche un avertissement : le calcul standard des amendes est remplacé par tel plugin.

OPAC

  • Afficher le mot de passe — Le formulaire de connexion a un lien qui affiche le mot de passe saisi.

  • Inscription en ligne — Le formulaire vérifie que l'âge correspond à la catégorie d'adhérent. La nouvelle préférence système PatronSelfRegistrationAgeRestriction fixe un âge maximal. Le choix du site est masqué quand il n'y a qu'un site.

  • Contact — Quand un seul site est public, le lien Bibliothèques du menu devient Contact.

  • Envoi des listes — La nouvelle préférence système OPACDisableSendList empêche l'envoi des listes par courriel.

  • Compte de l'adhérent — Le tableau des prêts affiche la date du prêt. Le tableau des abonnements affiche la date de publication (texte).

  • Identifiants d'auteur (MARC21) — La préférence système OPACAuthorIdentifiersAndInformation ajoute à la page de détail d'une notice, à l'OPAC, un onglet Informations sur l'auteur. Pour chaque auteur lié à une notice d'autorité, cet onglet affiche des informations tirées de l'autorité : lieux de naissance et de décès, activité, profession, adresse, identifiants, etc. Les identifiants sont lus dans la zone 024 de l'autorité : la source en $2, l'identifiant en $a. Koha transforme les identifiants des sources qu'il connaît en liens vers le site correspondant : ORCID, VIAF, Scopus, etc. Les sources isni (ISNI) et wikidata (Wikidata) s'y ajoutent. Cette fonctionnalité ne concerne que le MARC21 : en UNIMARC, l'onglet n'est pas affiché.

Adhérents

  • Alerte des inscriptions en ligne — Avec la nouvelle préférence système PatronSelfRegistrationAlert, la page d'accueil de l'interface professionnelle signale les adhérents inscrits en ligne qui attendent d'être traités (catégorie PatronSelfRegistrationDefaultCategory).

  • Journalisation — Quand la préférence système BorrowersLog est activée, chaque modification de la fiche lecteur d'un adhérent est inscrite dans le journal des actions, avec l'ancienne et la nouvelle valeur de chaque champ modifié. Les attributs étendus de l'adhérent (Administration › Types d'attributs d'adhérent) échappaient à cette journalisation. Leur ajout, modification ou suppression est désormais journalisé, y compris par la modification d'adhérents par lot.

    Le numéro de carte a, lui, un traitement à part. Certaines bibliothèques veulent garder l'historique des numéros de carte d'un adhérent plus longtemps que celui des autres modifications, que l'on purge régulièrement. Avec la nouvelle préférence système CardnumberLog, chaque changement de numéro de carte fait l'objet d'une entrée distincte dans le journal (action Modification du numéro de carte), avec l'ancien et le nouveau numéro. Le script cleanup_database.pl peut ainsi purger les autres modifications en épargnant ces entrées, par exemple :

    cleanup_database.pl --confirm --logs 365 --log-module MEMBERS --log-action MODIFY

    Cette préférence fonctionne même si BorrowersLog est désactivée. Elle est activée par défaut sur les nouvelles installations, désactivée lors d'une mise à jour.

  • Attributs obligatoires — Un attribut d'adhérent peut être obligatoire à l'OPAC, dans l'interface professionnelle, ou les deux.

  • Crédits — Les pages Prêt et Détails de l'adhérent affichent les crédits et pas seulement les sommes dues.

  • Statut protégé — La modification d'adhérents par lot peut changer le statut protégé.

  • Listes d'adhérents — L'export peut être trié.

Notifications

  • Expiration de l'abonnement — La notification d'expiration du compte (MEMBERSHIP_EXPIRY) apparaît dans les préférences de messagerie de l'adhérent. Elle peut être rendue obligatoire par catégorie d'adhérent : l'adhérent choisit alors le mode d'envoi, mais ne peut pas la désactiver. Le script membership_expiry.pl peut produire des notifications imprimées.

  • Template Toolkit — Les notifications par défaut DUE, PREDUE, ODUE, OVERDUES_SLIP, CHECKOUT_NOTE et MEMBERSHIP_EXPIRY sont converties en Template Toolkit. PROBLEM_REPORT accepte Template Toolkit.

  • Format des dates — La méthode strftime simplifie la mise en forme des dates, éventuellement dans une langue donnée :

    [% borrower.dateexpiry.strftime('%d/%m/%Y') %]
[% borrower.dateexpiry.strftime('%d %B %Y', 'fr_FR') %]

  • Messages personnalisés — Les messages envoyés depuis la fiche lecteur de l'adhérent (module Adhérents (message personnalisé)) ont accès au site de connexion : [% branch.branchname %], [% branch.branchaddress1 %], etc.

  • Données des plugins — Une notification écrite en Template Toolkit n'a accès qu'aux données que Koha lui transmet : l'adhérent, l'exemplaire, la réservation, le site, etc. Un plugin qui gère ses propres données ne pouvait pas les faire figurer dans une notification. Un nouveau hook de plugin, notices_content, le permet. Au moment de préparer une notification, Koha appelle chaque plugin actif qui implémente ce hook, en lui transmettant le contexte de la notification : son code, son module, les objets concernés, etc. Le plugin renvoie les données qu'il veut, éventuellement différentes selon la notification. Elles sont accessibles dans le modèle de la notification sous plugin_content, suivi de l'espace de noms du plugin (déclaré dans ses métadonnées). Par exemple, pour un plugin dont l'espace de noms est innreach :

    [% plugin_content.innreach.centre_de_retrait %]

    Le hook a été conçu pour le PEB : quand une réservation est satisfaite, un plugin peut retrouver la demande de PEB correspondante et fournir à la notification le message adapté. Mais il peut servir à n'importe quel plugin.

Interface professionnelle

  • Onglet Exemplaires — Une barre latérale liste les codes à barres des exemplaires, pour aller directement à l'un d'eux. Chaque exemplaire peut être replié.

  • Tableau des exemplaires — La localisation a sa propre colonne. Avec la nouvelle préférence système AlwaysShowHoldingsTableFilters, les filtres du tableau sont affichés par défaut.

  • Instructions de connexion et note de circulation — Les préférences système StaffLoginInstructions et RoutingListNote deviennent des personnalisations HTML, qui peuvent varier selon la langue.

  • Champs supplémentaires — On peut ajouter des champs supplémentaires aux sites. La page d'administration des champs supplémentaires les regroupe par module.

  • Choix de plusieurs valeurs dans une liste — Certains champs de formulaire permettent de choisir plusieurs valeurs dans une liste, par exemple les sites auxquels un type de document est réservé. Il fallait jusqu'ici maintenir la touche Ctrl (Cmd sur Mac) enfoncée en cliquant sur chaque valeur, dans une liste souvent longue. Un clic sans Ctrl effaçait toute la sélection. Ces champs fonctionnent désormais comme un champ de saisie : on tape le début d'une valeur, la liste se réduit aux valeurs correspondantes, on en choisit une, puis on recommence pour la suivante. Les valeurs choisies s'affichent dans le champ, chacune avec une petite croix pour la retirer. Sont concernés :

    • le champ Limitation par site des types de document, des catégories d'adhérent, des catégories de valeurs autorisées, des types d'attributs d'adhérent et des types de débit et de crédit,
    • les types de document et les sites de l'export des notices,
    • les catégories d'adhérent, les types de document et les sites de la prolongation des dates de retour par lot,
    • les paramètres à choix multiple des rapports SQL.

  • Personnalisation CSS — Des classes CSS sont ajoutées aux pages d'accueil des rapports et de la circulation, ainsi qu'aux informations des exemplaires (moredetail.pl).

  • Audit de la base de données — Le résultat du script audit_database.pl, qui compare la base de données à la structure attendue, est affiché dans À propos de Koha.

Outils

  • Inventaire — Deux nouvelles cases à cocher affichent les exemplaires perdus et les exemplaires sans problème.

  • Journal des actions — Pour certaines actions, comme la modification d'un exemplaire ou d'un adhérent, Koha enregistre dans le journal, en plus de la description de l'action, la liste des seuls champs modifiés, avec leur ancienne et leur nouvelle valeur. Cette information était stockée dans la base de données (colonne action_logs.diff) mais n'apparaissait pas dans le visualiseur des journaux (Outils › Journaux). Une colonne Diff l'affiche désormais. C'est une première étape : la différence est affichée telle qu'elle est stockée, au format JSON, où O désigne l'ancienne valeur et N la nouvelle. Par exemple, pour un exemplaire changé de site de rattachement :

    {"D":{"homebranch":{"N":"CENTRE","O":"ANNEXE"}}}

    La colonne figure dans les exports et les impressions du journal. Elle peut être masquée par défaut dans Administration › Paramétrage des tableaux.

Recherche

  • Titres exacts en tête des résultats (Elasticsearch) — Avec Zebra, une recherche par mot-clé combinait plusieurs recherches, dont une recherche du titre exact. Les bibliothèques passées à Elasticsearch constatent qu'une recherche la peste ne renvoie plus forcément en tête le roman de Camus, La Peste : des notices qui contiennent le mot « peste » ailleurs, dans un sous-titre, un sujet ou un résumé, passent devant. La nouvelle préférence système ElasticsearchBoostFieldMatch corrige cela. Quand elle est activée, Koha ajoute à la recherche une seconde requête, facultative, qui ne change pas la liste des résultats, mais fait remonter dans le classement les notices dont l'index recherché correspond aux termes saisis. Pour une recherche par mot-clé ou par titre, cette seconde requête porte sur l'index title-cover, le titre propre. Pour une recherche sur un autre index (auteur, sujet…), elle porte sur cet index. La préférence ElasticsearchBoostFieldMatchAmount règle l'importance de ce bonus. Les recherches en syntaxe CCL (ti:la peste) ne sont pas concernées.

    Attention en UNIMARC : dans les correspondances Elasticsearch livrées avec Koha, l'index title-cover n'est alimenté qu'en MARC21 (245$a). Pour que les recherches par mot-clé et par titre en profitent, il faut lier title-cover au 200$a dans Administration › Configuration de recherche (Elasticsearch), puis réindexer.

  • Numéro d'éditeur (MARC21) — Le numéro d'éditeur ou de distributeur (028$a), par exemple la référence d'un disque, est indexé comme numéro normalisé : on le trouve par la recherche avancée, Numéro normalisé. Les installations existantes doivent ajouter la correspondance et réindexer.

  • Recherche d'exemplaires — La date de dernier prêt a un sélecteur de date.

  • SRU — Un index public cible (audience) est ajouté.

Rapports

  • Paramètres à choix multiple — Un rapport SQL peut demander des valeurs à l'utilisateur au moment de son exécution, au moyen de paramètres écrits entre << et >>. Avec le suffixe :in, le paramètre accepte plusieurs valeurs, choisies dans une liste : sites, types de document, valeurs autorisées, etc. Koha remplace le paramètre par la liste des valeurs choisies, entre parenthèses, à utiliser avec IN. Par exemple, pour compter les exemplaires de plusieurs sites :

    SELECT homebranch, COUNT(*)
FROM items
WHERE homebranch IN <<Sites|branches:in>>
GROUP BY homebranch

    Jusqu'ici, la liste s'affichait en entier et il fallait maintenir la touche Ctrl enfoncée pour choisir plusieurs valeurs. C'est désormais un champ de saisie avec recherche : on tape le début d'une valeur, on la choisit, puis on recommence. Chaque valeur choisie s'affiche avec une petite croix pour la retirer.

  • Adhérents qui empruntent le plus — Le rapport affiche le total, à l'écran et dans l'export CSV.

Scripts en ligne de commande

  • cleanup_database.pl — Les options --statistics-type et --statistics-type-pseudo limitent la purge des statistiques à certains types, par exemple ceux déjà repris dans les transactions pseudonymisées.

  • delete_patrons.pl — L'option --without_restriction_type épargne les adhérents qui ont une restriction d'un type donné.

  • rebuild_zebra.pl — L'option --processes parallélise l'export des notices, ce qui accélère la réindexation.

  • compare_es_to_db.pl — L'option --fix corrige les différences entre l'index Elasticsearch et la base de données.

API REST

  • Règles de circulation — Un point d'accès permet de définir des règles de circulation.

  • Priorité de réservation — La priorité la plus basse d'une réservation peut être activée ou désactivée.

Sécurité

  • Perl dans les modèles — Dans l'interface professionnelle, le personnel écrit de nombreux modèles en Template Toolkit : notifications, modèles de mise en forme des rapports, profils d'export CSV, champs SIP2 personnalisés, etc. Template Toolkit a deux options dangereuses, que Koha activait pour ces modèles :

    • EVAL_PERL permet d'insérer du code Perl dans un modèle, entre [% PERL %] et [% END %]. Ce code est exécuté sur le serveur, avec les droits de Koha : il peut lire la configuration (donc le mot de passe de la base de données) ou exécuter n'importe quelle commande.
    • ABSOLUTE permet d'inclure dans un modèle n'importe quel fichier du serveur, par son chemin complet, par exemple [% INSERT /etc/koha/sites/biblio/koha-conf.xml %].

    Il suffisait donc d'avoir le droit de modifier une notification pour prendre la main sur le serveur. Ces deux options sont désormais désactivées pour les modèles saisis par les utilisateurs. Elles restent actives pour les modèles livrés avec Koha, qui ne sont pas modifiables depuis l'interface. Un modèle qui contient un bloc [% PERL %] ne fonctionne plus et doit être réécrit, au besoin avec un plugin Template Toolkit.

Architecture, fonctionnement interne et plomberie

  • Mise en forme du code — L'ensemble du code source est mis en forme automatiquement (Perl, JavaScript, Vue.js, modèles Template Toolkit). Un hook Git applique cette mise en forme à chaque commit et le script de contrôle qualité la vérifie.

  • Vue.js — Des îlots Vue.js peuvent être insérés dans des pages classiques, comme le menu des acquisitions. Les permissions sont accessibles aux applications Vue.

  • Tableaux — L'ancienne implémentation KohaTable est supprimée : tous les tableaux utilisent kohaTable.

  • Indexation Elasticsearch par un plugin — Pour indexer une notice dans Elasticsearch, Koha la convertit en un document : une liste d'index (titre, auteur, sujet…) avec leurs valeurs, tirées des zones MARC selon les correspondances définies dans Administration › Configuration de recherche. Ce que l'on peut indexer se limite donc au contenu de la notice, tel que ces correspondances permettent de le découper.

    Un nouveau hook de plugin, elasticsearch_to_document, est appelé pour chaque notice, bibliographique ou d'autorité, juste avant l'envoi du document à Elasticsearch. Le plugin reçoit la notice MARC et le document, qu'il peut compléter ou modifier. Il peut ainsi :

    • ajouter des index calculés, qui ne correspondent à aucune zone MARC,
    • normaliser ou nettoyer des valeurs existantes,
    • interroger un service externe à partir d'un identifiant de la notice, par exemple récupérer dans VIAF les formes alternatives du nom d'un auteur, ou encore récupérer les formes traduites de termes Opentheso avec le plugin Tamil Opentheso,
    • télécharger un fichier référencé dans la notice (un PDF en 856$u, par exemple) et indexer son contenu en texte intégral.

Préférences système

Nouvelles préférences :

  • AlwaysShowHoldingsTableFilters
  • AutoILLBackendPriority
  • AutomaticEmailReceipts (anciennement UseEmailReceipts)
  • CardnumberLog
  • ConsiderHeadingUse
  • ElasticsearchBoostFieldMatch
  • HoldCancellationRequestSIP
  • ILLHistoryCheck
  • ILLOpacUnauthenticatedRequest
  • ILLRequestsTabs
  • LanguageToUseOnMerge
  • LinkerConsiderDiacritics
  • OPACDisableSendList
  • PatronSelfRegistrationAgeRestriction
  • PatronSelfRegistrationAlert
  • TransfersLog

Préférences supprimées :

  • RoutingListNote (remplacée par une personnalisation HTML)
  • StaffLoginInstructions (remplacée par une personnalisation HTML)