Tamil
Actualité

Koha 23.11

jeudi 30 novembre 2023
Koha 23.11

Koha 23.11 apporte 10 nouvelles fonctionnalités, 330 améliorations et 573 corrections de bugs. Deux nouveaux modules apparaissent : la conservation, qui suit les traitements des documents (reliure, restauration) ; les statistiques d'utilisation des ressources électroniques, dans l'ERM. Un exemplaire peut être réservé pour une période donnée. Un fonds flottant peut être limité à un groupe de sites. À l'OPAC, l'adhérent peut emprunter lui-même un document en scannant son code à barres. Un bandeau recueille son consentement aux cookies. Les courriels d'un enfant peuvent être copiés à son garant. Le module de PEB permet de créer des demandes par lots.

Circulation

Réservations programmées 🆕

Une réservation ordinaire porte sur le prochain exemplaire disponible. La réservation programmée (booking) porte, elle, 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. Un exemplaire devient pré-réservable quand on passe son champ Pré-réservable à Oui. Dès qu'une notice a au moins un exemplaire pré-réservable, sa page de détail affiche un bouton Programmer une réservation et un onglet qui liste ses réservations programmées. Deux réservations programmées d'un même exemplaire ne peuvent pas se chevaucher. Au moment d'un prêt, Koha avertit le personnel si l'exemplaire est réservé pour une période qui commence avant la date de retour.

C'est une première version, enrichie dans les versions suivantes.

Fonds flottant par groupe de sites 🆕

Dans un réseau, un exemplaire rendu dans un autre site que son site de rattachement peut être renvoyé chez lui, ou rester là où il a été rendu : c'est un fonds flottant. Les règles de circulation proposaient de faire flotter un exemplaire partout ou nulle part. Une nouvelle option, Exemplaire flottant par groupe de bibliothèques, le fait flotter seulement à l'intérieur d'un groupe de sites. Le groupe se définit dans Administration › Groupes de bibliothèques, en cochant Est un groupe local flottant. Par exemple, dans un réseau intercommunal, les exemplaires circulent librement entre les médiathèques d'une même commune, mais retournent dans leur commune quand ils sont rendus ailleurs.

Plus

  • Localisation mise à jour au prêt — La préférence système UpdateItemLocationOnCheckin change la localisation d'un exemplaire au retour. La nouvelle préférence UpdateItemLocationOnCheckout fait de même au prêt. On y écrit des paires de localisations, par exemple NOUV: GEN pour qu'un exemplaire du présentoir des nouveautés rejoigne le fonds général quand il est prêté. _ALL_ désigne toutes les localisations, _PERM_ la localisation permanente de l'exemplaire et _BLANK_ une localisation vide.

  • Statut d'exclusion du prêt au retour — La préférence système UpdateNotForLoanStatusOnCheckin change le statut d'exclusion du prêt d'un exemplaire quand il est rendu. Elle peut désormais avoir des règles différentes selon le type de document, ou _ALL_ pour tous les types :

    LIVRE:
  -1: 0
_ALL_:
  -1: 2

  • Renouvellement automatique — Une nouvelle règle de circulation, Pas de renouvellement automatique avant, distingue le délai avant lequel un renouvellement automatique est impossible de celui des renouvellements manuels. Quand un renouvellement automatique est le dernier permis, l'adhérent en est averti dans la notification AUTO_RENEW.

  • Retour automatique et réservations — Certains documents prêtés ne sont jamais rapportés à la bibliothèque. C'est le cas d'un pass pour un musée, sous forme de code ou de billet électronique, prêté pour une semaine : il n'y a rien à rendre, mais la bibliothèque veut qu'un même adhérent ne l'ait que pour une période limitée. C'est aussi le cas d'une grainothèque : les graines empruntées ne reviennent pas. Pour ces documents, on coche Retour automatique dans leur type de document (Administration › Types de document). Le script misc/cronjobs/automatic_checkin.pl, lancé toutes les heures par la crontab de Koha, rend alors automatiquement les prêts de ce type arrivés à échéance : ils disparaissent de la fiche lecteur sans intervention du personnel. Avec la nouvelle préférence système AutomaticCheckinAutoFill, ce retour automatique satisfait aussi la réservation suivante : l'exemplaire est mis de côté pour l'adhérent qui l'attend et celui-ci est prévenu qu'il est disponible. Le pass passe ainsi d'un adhérent à l'autre sans que le personnel ait à intervenir.

  • Prêt par lot sur place — Le prêt par lot propose l'option de prêt sur place.

  • Page de prêt — La nouvelle préférence système LoadCheckoutsTableDelay retarde de quelques secondes le chargement de la liste des prêts en cours, pour pouvoir prêter sans attendre quand cette liste est longue. Le bouton qui renouvelait ou rendait les prêts sélectionnés est remplacé par deux boutons distincts.

  • Expéditeur des avis de retard — La préférence système OverdueNoticeFrom accepte une nouvelle valeur : le site de rattachement de l'adhérent.

  • Retours — La liste des retours indique le motif d'un transfert.

Réservations

  • Délai de retrait par règle — Le délai pendant lequel une réservation attend son adhérent était fixé pour tout le réseau par la préférence système ReservesMaxPickUpDelay. Il peut désormais être défini dans les règles de circulation, par site, catégorie d'adhérent et type de document : par exemple 3 jours pour un DVD très demandé et 10 jours pour un livre.

  • Confirmation d'une réservation — Avec la nouvelle préférence système EmailPatronWhenHoldIsPlaced, l'adhérent reçoit un courriel qui confirme sa réservation (notification HOLDPLACED_PATRON).

  • Réservations à retirer regroupées — Un adhérent qui a plusieurs réservations à retirer recevait un courriel par document. Il peut désormais cocher Résumés uniquement pour l'événement Réservation remplie dans ses préférences de messagerie : il reçoit alors un seul courriel qui les récapitule toutes (notification HOLDDGST).

  • Réservation d'exemplaire en réservation de notice — Le personnel peut transformer une réservation qui porte sur un exemplaire précis en réservation sur la notice, quand c'est possible.

  • Notes de réservation — Elles s'affichent dans la liste des réservations de la fiche lecteur.

Acquisitions

  • Problèmes rencontrés avec un fournisseur 🆕 — Pour un fournisseur de ressources électroniques, une interruption de service, un problème de connexion ou un accès qui ne correspond pas au contrat sont des faits à garder en mémoire : ils pèsent lors de la renégociation du contrat. La fiche d'un fournisseur a désormais un onglet où l'on enregistre ces problèmes, avec leur type, leurs dates de début et de fin et une note. Les types se définissent dans la nouvelle catégorie de valeurs autorisées VENDOR_ISSUE_TYPE. Une nouvelle permission, issue_manage, permet de les gérer.

  • Adresses des courriels — Quatre nouvelles préférences système fixent l'adresse d'expédition et l'adresse de réponse des courriels envoyés aux fournisseurs : commandes et réclamations d'acquisitions (AcquisitionsDefaultEMailAddress, AcquisitionsDefaultReplyTo), réclamations de périodiques (SerialsDefaultEMailAddress, SerialsDefaultReplyTo).

  • Montants hors taxes — Avec la nouvelle préférence système CalculateFundValuesIncludingTax, les montants engagés et dépensés sur un fonds peuvent être calculés hors taxes, même si les prix sont saisis TTC. C'est utile pour une bibliothèque qui récupère la TVA.

  • Annulation dans un panier fermé — Avec la nouvelle préférence système CancelOrdersInClosedBaskets, on peut annuler une ligne de commande d'un panier fermé, par exemple un document que le fournisseur ne peut pas livrer, sans rouvrir le panier.

  • Quantité commandée — La préférence système AcqCreateItem choisit le moment où Koha crée les exemplaires d'une commande : à la commande, à la réception ou au catalogage. Quand ils sont créés à la commande, une ligne de commande de trois exemplaires comprend trois exemplaires saisis un par un dans le formulaire de commande, avec leur site, leur cote, etc. La quantité d'une ligne déjà enregistrée ne pouvait plus être modifiée : pour commander un quatrième exemplaire, il fallait créer une nouvelle ligne de commande. Le formulaire de modification d'une ligne affiche désormais la liste de ses exemplaires et le formulaire d'ajout d'exemplaire : chaque exemplaire ajouté augmente la quantité commandée. Les exemplaires déjà enregistrés ne peuvent pas y être modifiés.

  • Réserver un document commandé — Le résumé d'un panier a un lien pour réserver un document commandé.

  • Factures — Le résumé d'un panier a une colonne Facture, avec un lien vers la facture des lignes reçues.

  • Montants — Les montants saisis dans le module Acquisitions sont vérifiés avant d'être enregistrés.

  • Recherche de commandes — Elle peut porter sur tous les statuts et est accessible depuis le menu du module.

ERM

  • Statistiques d'utilisation 🆕 — Évaluer un abonnement électronique suppose d'en connaître l'usage réel. Les éditeurs et les plateformes fournissent ces chiffres dans un format normalisé, COUNTER, que l'on récupère automatiquement par le protocole SUSHI. Le module ERM a désormais une section Statistiques d'utilisation. On y déclare chaque fournisseur de données (éditeur ou plateforme), avec ses identifiants SUSHI et les rapports COUNTER à récupérer : par titre, par base de données, par plateforme, par élément. Koha moissonne ces rapports, à la demande ou chaque nuit avec le script misc/cronjobs/erm_run_harvester.pl. On peut ensuite construire ses propres rapports sur ces données, par exemple le nombre de téléchargements d'articles d'une revue mois par mois.

PEB

  • Lots de demandes 🆕 — Un chercheur qui prépare une bibliographie peut avoir besoin de dizaines d'articles. Plutôt que de créer une demande de PEB par article, le personnel peut créer un lot à partir d'une liste de DOI ou d'identifiants PubMed. Koha complète les références de chaque article grâce à un plugin d'enrichissement (Crossref pour les DOI, PubMed), puis crée les demandes. Il faut un backend de PEB compatible.

  • Avertissement par type de demande 🆕 — La nouvelle préférence système ILLModuleDisclaimerByType affiche, après le formulaire de demande et avant son enregistrement, un texte que l'adhérent ou le personnel doit accepter, différent selon le type de demande : par exemple un rappel des règles du droit de copie pour une demande d'article. La réponse et sa date sont enregistrées avec la demande.

  • Demandes à l'OPAC par catégorie — Quand le module de PEB est activé, les adhérents peuvent faire eux-mêmes une demande de PEB depuis leur compte à l'OPAC. Jusqu'ici, c'était tout ou rien : tous les adhérents en avaient la possibilité. Or une bibliothèque universitaire peut vouloir réserver le PEB aux enseignants et aux doctorants, ou une bibliothèque publique l'interdire aux comptes de collectivités. Chaque catégorie d'adhérent a désormais un réglage Peut faire des demandes de PEB à l'OPAC (Administration › Catégories d'adhérents). Les adhérents d'une catégorie qui ne l'a pas ne voient plus la possibilité de faire une demande à l'OPAC ; le personnel peut toujours en faire pour eux. Lors de la mise à jour, toutes les catégories reçoivent ce droit : rien ne change tant qu'on ne le retire pas.

  • Bibliothèques partenaires — Dans Koha, les bibliothèques auxquelles on emprunte des documents par PEB sont enregistrées comme des adhérents, avec leur adresse électronique, dans une catégorie d'adhérent qui leur est réservée. Depuis une demande de PEB, l'action Demander à des partenaires propose ces bibliothèques : on choisit à qui écrire et Koha leur envoie un courriel rédigé à partir de la notification ILL_PARTNER_REQ. La catégorie des partenaires était indiquée par le paramètre partner_code du fichier koha-conf.xml sur le serveur. Seul l'administrateur du serveur pouvait la changer. À défaut, Koha utilisait la catégorie IL. La catégorie se choisit désormais dans l'interface professionnelle, dans la liste des catégories d'adhérents proposée par la nouvelle préférence système ILLPartnerCode.

  • Annulation — Une demande envoyée à un partenaire peut être annulée.

Conservation 🆕

Le nouveau module Conservation suit les traitements matériels des documents : reliure, restauration, désacidification, numérisation, etc. Il s'active avec la préférence système PreservationModule et son accès dépend d'une nouvelle permission, preservation.

Traitements

Un traitement (Traitements, dans les paramètres du module) décrit une opération, par exemple « Reliure ». On lui associe les informations à saisir pour chaque document traité, appelées attributs. Un attribut peut être :

  • une valeur choisie dans une catégorie de valeurs autorisées : la couleur de la reliure, le type de papier ;
  • un texte libre : une consigne particulière au relieur ;
  • une colonne de la table des exemplaires, dont la valeur est reprise automatiquement : la cote ou le code à barres, à imprimer sur le dos de la reliure.

Chaque traitement peut avoir sa propre notification, pour imprimer la fiche qui accompagne le document chez le prestataire. Par défaut, c'est la notification PRES_TRAIN_ITEM.

Liste d'attente

Les exemplaires à traiter sont d'abord placés en liste d'attente, par leur code à barres. Ils prennent alors le statut d'exclusion du prêt indiqué par la préférence PreservationNotForLoanWaitingListIn, par exemple En attente de reliure : ils ne peuvent plus être prêtés. La liste d'attente n'est pas une table : ce sont simplement les exemplaires qui ont ce statut. Retirer un exemplaire de la liste d'attente remet son statut d'exclusion du prêt à 0.

Lots

Les exemplaires de la liste d'attente sont ensuite répartis dans des lots, par exemple un lot par envoi chez le relieur. Un lot a un nom, une description, un traitement par défaut et un statut d'exclusion du prêt, par défaut celui de la préférence PreservationNotForLoanDefaultTrainIn, qu'il donne aux exemplaires qu'on lui ajoute. Pour chaque exemplaire, on saisit les attributs du traitement, ou d'un autre traitement que celui du lot. Un lot est successivement fermé (on ne peut plus y ajouter d'exemplaires), envoyé puis réceptionné : Koha garde la date de chaque étape. Les fiches s'impriment une par une ou pour tout le lot. Un exemplaire peut être copié dans un autre lot, pour enchaîner deux traitements, par exemple une restauration puis une numérisation.

Tables de la base de données

Le module ajoute cinq tables, que l'on peut interroger dans des rapports SQL :

  • preservation_processings : les traitements (processing_id, name, letter_code) ;
  • preservation_processing_attributes : les attributs de chaque traitement (processing_id, name, type et option_source) : type vaut authorised_value, free_text ou db_column ; option_source contient la catégorie de valeurs autorisées ou la colonne d'origine ;
  • preservation_trains : les lots (train_id, name, description, default_processing_id, not_for_loan ainsi que les dates created_on, closed_on, sent_on et received_on) ;
  • preservation_trains_items : les exemplaires de chaque lot (train_id, item_id, lié à items.itemnumber, processing_id, added_on) ;
  • preservation_processing_attributes_items : les valeurs des attributs saisies pour chaque exemplaire d'un lot (train_item_id, processing_attribute_id, value).

Par exemple, pour lister les exemplaires partis en traitement et pas encore revenus :

SELECT t.name AS lot, t.sent_on AS envoi, p.name AS traitement,
       i.barcode, i.itemcallnumber
FROM preservation_trains t
JOIN preservation_trains_items ti ON ti.train_id = t.train_id
JOIN items i ON i.itemnumber = ti.item_id
LEFT JOIN preservation_processings p ON p.processing_id = ti.processing_id
WHERE t.sent_on IS NOT NULL AND t.received_on IS NULL
ORDER BY t.sent_on, i.itemcallnumber

Catalogage

  • Éditeur avancé — Quand l'éditeur de catalogage avancé est activé (EnableAdvancedCatalogingEditor), un bouton permet de passer de l'éditeur de base à l'éditeur avancé ou l'inverse.

  • Erreurs dans les autorités — Les erreurs de saisie d'une autorité (une zone obligatoire vide, par exemple) ne s'affichent plus dans une fenêtre d'alerte, mais en haut de la page, avec un lien vers chaque zone concernée.

  • Plugin de recherche d'autorités — Un lien vide d'un coup tous les champs du formulaire de recherche.

  • UNIMARC 123 — La zone 123 décrit les données mathématiques codées d'un document cartographique. Ses sous-zones $d, $e, $f et $g donnent les coordonnées du territoire représenté : longitudes ouest et est, latitudes nord et sud, sous la forme hdddmmss (hémisphère, degrés, minutes, secondes), par exemple E0022000 pour 2° 20′ Est. Un plugin de catalogage aide à les saisir. Il en existait quatre, un par sous-zone, presque identiques. Ils sont remplacés par un seul, unimarc_field_123defg.pl. La mise à jour de Koha modifie automatiquement toutes les grilles de catalogage qui utilisaient les anciens plugins : il n'y a rien à faire. Attention seulement à une grille exportée avant la mise à jour et réimportée ensuite : elle ferait encore appel aux anciens plugins, qui n'existent plus.

  • Lien « Afficher les volumes » — Il ne s'affiche plus que si la notice a effectivement des volumes liés.

  • Étiquettes — La largeur et la hauteur du code à barres imprimé sur les étiquettes sont réglables.

  • MARC21 — La grille de catalogage MARC21 par défaut intègre les mises à jour 31 à 36 du format (2020 à 2023). La liste des fonctions (RELTERMS) est mise à jour. Ces changements ne concernent que les nouvelles installations.

Autorités

  • Onglet par défaut — La nouvelle préférence système DefaultAuthorityTab choisit l'onglet affiché en premier sur la page d'une autorité : 1XX, 2XX, etc.

  • Recherche Z39.50 d'autorités — La nouvelle préférence système AdditionalFieldsInZ3950ResultAuthSearch ajoute aux résultats d'une recherche Z39.50 d'autorités le contenu de zones choisies, par exemple 001, 035$a, pour mieux identifier la bonne autorité.

OPAC

  • Consentement aux cookies 🆕 — Avec la nouvelle 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. Les scripts de suivi, par exemple les statistiques de fréquentation Matomo, ne doivent plus être placés dans OPACUserJS ou IntranetUserJS, mais dans la nouvelle préférence CookieConsentedJS : ils ne s'exécutent alors qu'avec l'accord du visiteur.

  • Prêt en libre service à l'OPAC 🆕 — Koha avait déjà un module de prêt en libre service, le module SCO (/cgi-bin/koha/sco/sco-main.pl). C'est une application à part, conçue pour un poste installé dans la bibliothèque : il fonctionne avec un compte de personnel dédié (ou une plage d'adresses IP autorisées), l'adhérent s'y identifie avec sa carte puis y emprunte, renouvelle et parfois rend ses documents. Le poste se déconnecte au bout d'un délai, pour l'adhérent suivant.

    Avec la nouvelle préférence système OpacTrustedCheckout, le prêt en libre service est aussi possible depuis l'OPAC, dans le compte de l'adhérent lui-même, sur n'importe quel ordinateur ou téléphone. Une fois connecté, l'adhérent voit un lien Prêt en libre service en haut de la page. Il ouvre une fenêtre où l'adhérent saisit ou scanne le code à barres d'un document pour se le prêter. Koha applique les mêmes règles qu'à la banque de prêt : un prêt impossible est refusé avec son motif et un prêt qui demande une confirmation (un document réservé par un autre adhérent, par exemple) doit être confirmé par l'adhérent. La fenêtre ne permet que le prêt : pas de retour ni de renouvellement.

    Le terme trusted (de confiance) dit l'essentiel : la bibliothèque fait confiance à ses adhérents, puisque personne ne vérifie ce qui sort et qu'il n'y a pas d'antivol à désactiver. C'est adapté à une petite bibliothèque sans automate de prêt, ou à une bibliothèque d'entreprise ou de laboratoire dont les usagers ont accès aux rayons en l'absence du personnel.

  • CSS et JavaScript par site — Les préférences système OPACUserCSS et OPACUserJS personnalisent l'apparence et le comportement de l'OPAC pour tout le réseau. Chaque site peut désormais avoir, en plus, sa propre feuille de style et son propre JavaScript, saisis dans sa fiche (Administration › Sites, champs CSS spécifique pour l'OPAC et JS spécifique pour l'OPAC). Cela ne concerne que l'OPAC, y compris les pages du prêt et du retour en libre service : l'interface professionnelle n'est pas concernée. Le code du site s'ajoute à celui des préférences, après lui : il peut donc le compléter ou le corriger.

    Reste à savoir quel site s'applique. Si l'adhérent est connecté, c'est son site de rattachement : un adhérent de l'annexe voit l'OPAC aux couleurs de l'annexe. Sinon, c'est le site par défaut de l'OPAC, fixé par la variable OPAC_BRANCH_DEFAULT dans la configuration Apache. Un réseau peut ainsi publier plusieurs OPAC, chacun à sa propre adresse et à l'apparence de son site, à partir d'une seule installation de Koha. Sans cette variable, le visiteur non connecté ne voit que la personnalisation commune.

  • Alertes de périodiques — Une nouvelle page du compte de l'adhérent liste les abonnements de périodiques pour lesquels il a demandé à être averti de l'arrivée d'un nouveau numéro. Il peut y annuler ces alertes. La page existe aussi dans l'interface professionnelle.

  • Listes — Depuis une liste, on peut ajouter des notices au panier ou à une autre liste.

  • Inscription en ligne — Le formulaire propose la langue des notifications quand la préférence TranslateNotices est activée.

  • Personnalisations HTML — Les préférences OpacMaintenanceNotice, OPACResultsSidebar, OpacSuppressionMessage et PatronSelfRegistrationAdditionalInstructions deviennent des personnalisations HTML, qui peuvent varier selon la langue. Leur contenu est repris lors de la mise à jour.

  • Accessibilité — Plusieurs liens et formulaires sont rendus plus explicites pour les lecteurs d'écran.

Adhérents

  • Courriels copiés au garant 🆕 — Avec la nouvelle préférence système RedirectGuaranteeEmail, les courriels envoyés à un adhérent qui a un garant, un enfant par exemple, sont aussi envoyés à son garant. Si l'adhérent n'a pas d'adresse électronique, ils sont envoyés au garant seul. Les parents sont ainsi prévenus des retards ou des réservations à retirer de leurs enfants.

  • Garant obligatoire — Avec la nouvelle préférence système ChildNeedsGuarantor, un adhérent d'une catégorie de type Enfant, ou d'une catégorie qui accepte les garants, ne peut pas être inscrit sans garant. Un garant ne peut pas lui-même avoir de garant.

  • Adhérents protégés — Un adhérent peut être protégé : il ne peut plus être supprimé ni fusionné avec un autre, ni depuis l'interface ni par les scripts de suppression. C'est utile pour les fiches lecteur qui servent au fonctionnement de la bibliothèque, comme celles des bibliothèques partenaires du PEB ou des automates de prêt.

  • Dernière activité — Koha peut enregistrer la date de dernière activité de chaque adhérent. La préférence système TrackLastPatronActivity devient TrackLastPatronActivityTriggers : on choisit désormais les actions qui mettent cette date à jour (connexion, prêt, retour, renouvellement, réservation, demande d'article, connexion par SIP2 ou ILS-DI).

  • Renouvellement automatique de l'inscription — Le script misc/cronjobs/membership_expiry.pl, lancé chaque nuit, avertit les adhérents dont l'inscription expire dans le nombre de jours fixé par la préférence système MembershipExpiryDaysNotice (notification MEMBERSHIP_EXPIRY). Avec la nouvelle option --renew, il renouvelle plutôt leur inscription, pour la durée prévue par leur catégorie. Il les en informe par la notification MEMBERSHIP_RENEWED. C'est utile quand l'inscription est gratuite et que la bibliothèque ne veut pas perdre ses lecteurs pour une simple formalité.

    Deux nouvelles options limitent le traitement selon l'activité des adhérents. Avec --active 12, le script ne traite que les adhérents actifs depuis 12 mois ; avec --inactive 12, seulement ceux qui ne l'ont pas été. On peut ainsi renouveler les adhérents actifs et avertir les autres, en lançant le script deux fois. La crontab quotidienne de Koha le lance sans ces options : il faut l'adapter, par exemple ainsi :

    membership_expiry.pl -c --renew --active 12
membership_expiry.pl -c --inactive 12

    Un adhérent est considéré comme actif sur la période s'il s'est inscrit pendant celle-ci ou si sa date de dernière activité (borrowers.lastseen) s'y trouve. Cette date n'est mise à jour que par les actions choisies dans la préférence TrackLastPatronActivityTriggers : connexion, prêt, retour, renouvellement, réservation, etc. Ces options supposent donc que la préférence soit en place depuis au moins la période indiquée ; sinon, des adhérents actifs passeront pour inactifs.

  • Restriction des adhérents débiteurs — Le nouveau script misc/cronjobs/debar_patrons_with_fines.pl pose une restriction aux adhérents qui doivent plus d'un certain montant à la bibliothèque (option --amount).

  • Levée d'une restriction après paiement — Un type de restriction (Administration › Types de restriction) peut être levé automatiquement quand l'adhérent a payé ce qu'il doit, ou quand sa dette passe sous un montant donné.

  • Recherche d'adhérents — La nouvelle préférence système DefaultPatronSearchMethod choisit si la recherche porte sur le début des champs (Commence par) ou sur n'importe quelle partie (Contient). Les attributs d'adhérent interrogeables sont proposés dans la liste des champs de recherche. La préférence DefaultPatronSearchFields se règle en cochant les champs dans une fenêtre.

  • Listes d'adhérents — Les listes d'adhérents (Outils › Listes d'adhérents) regroupent des adhérents pour un traitement commun : une modification par lot, l'impression de cartes, etc. La fiche lecteur et la page de prêt ont désormais un onglet Listes d'adhérents. Il indique les listes dont l'adhérent fait partie et permet de l'en retirer, liste par liste, ou de l'ajouter à une autre liste, sans passer par le module Outils. Par ailleurs, dans Outils › Listes d'adhérents, on peut sélectionner plusieurs listes et les supprimer d'un coup, au lieu de les supprimer une par une.

  • Historique des réservations — L'onglet de l'historique des réservations de la fiche lecteur était affiché ou masqué avec celui de l'historique des prêts (préférence intranetreadinghistory). Il dépend désormais de sa propre préférence, intranetReadingHistoryHolds : on peut consulter les réservations passées d'un adhérent sans avoir accès à ses prêts passés.

Notifications

  • Tickets personnalisés — Un nouveau module de notifications, Adhérents (ticket personnalisé), permet de créer des tickets qui apparaissent dans le menu Imprimer de la fiche lecteur : par exemple un récapitulatif des pièces justificatives à fournir.

Interface professionnelle

  • Derniers adhérents consultés — Avec la préférence système showLastPatron, un bouton Dernier adhérent, en haut des pages de l'interface professionnelle, ramène à la fiche du dernier adhérent consulté. C'est pratique à la banque de prêt : on quitte la fiche d'un lecteur pour chercher une notice ou vérifier un exemplaire, puis on y revient d'un clic. Mais le bouton ne retenait qu'un seul adhérent : dès qu'on en avait ouvert un autre, le précédent était perdu. Le bouton a désormais une flèche qui déroule la liste des adhérents consultés récemment, avec leur nom et leur numéro de carte, le plus récent en premier. On peut ainsi revenir à un lecteur servi quelques minutes plus tôt, même si l'on a traité d'autres adhérents entre-temps. La nouvelle préférence système showLastPatronCount fixe le nombre d'adhérents retenus : 10 par défaut. La liste est conservée dans le navigateur de chaque poste.

  • Choix du site à la connexion — Avec la nouvelle préférence système ForceLibrarySelection, le personnel doit choisir son site en se connectant à l'interface professionnelle.

  • Recherche d'exemplaires — Les exemplaires sélectionnés sont mémorisés d'une page de résultats à l'autre et peuvent être modifiés ou supprimés par lot. On peut limiter la recherche aux exemplaires endommagés.

  • Serveur SMTP par défaut — Un serveur SMTP peut être désigné comme serveur par défaut de tous les sites, au lieu d'être attribué à chaque site.

  • Personnalisation des pages d'accueil des modules — L'outil Personnalisations HTML (Outils › Personnalisations HTML) permet d'ajouter du contenu à des emplacements prédéfinis de l'OPAC ou de l'interface professionnelle. Dans l'interface professionnelle, il n'y en avait aucun : seule la page d'accueil générale pouvait recevoir un texte, par la préférence système IntranetmainUserblock. Sept nouveaux emplacements ajoutent du contenu en bas de la page d'accueil d'un module :

    • StaffAcquisitionsHome : Acquisitions ;
    • StaffAuthoritiesHome : Autorités ;
    • StaffCataloguingHome : Catalogage ;
    • StaffListsHome : Listes ;
    • StaffPatronsHome : Adhérents ;
    • StaffPOSHome : Point de vente ;
    • StaffSerialsHome : Périodiques.

    On peut y mettre des consignes de travail, un lien vers une procédure interne ou un rappel : par exemple, sur la page d'accueil du Catalogage, les règles locales de saisie des cotes, ou sur celle des Acquisitions, la date limite des commandes de l'année. Comme toute personnalisation HTML, ce contenu peut être rédigé dans plusieurs langues et réservé à un site : le personnel d'une annexe peut ainsi avoir ses propres consignes.

  • Préférences système — Une préférence qui attend une valeur autorisée propose une liste déroulante au lieu d'un champ de saisie.

  • Icônes — Les icônes passent à Font Awesome 6.

Recherche

  • Tri des liens d'auteur — Sur la page de détail d'une notice, le nom de chaque auteur est un lien qui lance une recherche de ses autres œuvres. Ces résultats suivaient le tri par défaut du catalogue, souvent la pertinence, peu utile ici : on cherche plutôt à voir l'œuvre d'un auteur dans l'ordre chronologique ou alphabétique. Les nouvelles préférences système AuthorLinkSortBy et AuthorLinkSortOrder fixent le tri propre à ces liens : par date de publication, titre, cote ou date d'ajout au catalogue, en ordre croissant ou décroissant. Par exemple, date de publication décroissante pour voir d'abord les ouvrages les plus récents.

    MARC21 seulement en 23.11 : seules les feuilles XSLT MARC21 fournies avec Koha tiennent compte de ces préférences. Les feuilles UNIMARC ne les prennent en charge que depuis Koha 25.11 (et les versions de maintenance 25.05.03 et 24.11.09). Le tri lui-même est le tri habituel du catalogue : il n'y a rien à paramétrer dans les index Elasticsearch ou Zebra. En revanche, une bibliothèque qui utilise ses propres feuilles XSLT doit y reprendre le code qui ajoute le tri aux liens d'auteur, faute de quoi les préférences restent sans effet.

  • Elasticsearch 8 et OpenSearch 2 — Koha fonctionne avec Elasticsearch 7 et 8 et avec OpenSearch 1 et 2. Elasticsearch 6 n'est plus pris en charge : il faut passer à une version plus récente avant la mise à jour. Le passage à Elasticsearch 8 ou OpenSearch 2 demande une réindexation.

Rapports

  • Mise en forme d'un rapport par une notification — Le résultat d'un rapport SQL s'affiche sous forme de tableau. Il peut désormais être mis en forme par un modèle de notification, écrit en Template Toolkit et en HTML comme les autres notifications. On crée la notification dans Outils › Notifications, dans le nouveau module Rapports. Elle reçoit les lignes du rapport dans la variable data, chaque colonne étant accessible par son nom. Par exemple, pour un rapport SELECT surname, firstname, dateexpiry FROM borrowers, ce modèle produit une fiche par adhérent au lieu d'un tableau :

    [% FOREACH b IN data %]
  <h3>[% b.surname %], [% b.firstname %]</h3>
  <p>Inscription valable jusqu'au [% b.dateexpiry %]</p>
[% END %]

    Sur la page du rapport, le bouton Exécuter avec le modèle propose les notifications du module Rapports : le résultat s'affiche alors mis en forme. On peut ainsi présenter une liste de nouveautés avec titres, auteurs et cotes, prête à être imprimée ou affichée.

    Le résultat mis en forme peut aussi être téléchargé comme un fichier, depuis le menu de téléchargement du rapport. Le nom du fichier est l'objet de la notification, qui peut lui-même contenir du Template Toolkit, par exemple la date du jour. On peut ainsi produire des fichiers dans n'importe quel format texte : HTML pour le site web de la bibliothèque, XML ou CSV à la présentation imposée par un partenaire, etc.

SIP2

  • Messages OPAC — Avec la nouvelle préférence système SIP2AddOpacMessagesToScreenMessage, les messages destinés à l'adhérent dans son compte à l'OPAC s'affichent aussi sur l'écran de l'automate de prêt.

  • Types de document bloqués — Un compte SIP2 peut interdire le prêt de certains types de document (paramètre blocked_item_types de SIPconfig.xml).

  • Champs autorisés — Un compte SIP2 peut lister les seuls champs autorisés dans ses réponses, plutôt que les champs à masquer.

  • Rappels — Un automate de prêt refuse de prêter un exemplaire rappelé pour un autre adhérent. Il satisfait le rappel quand il le prête à l'adhérent qui l'attend.

  • Retours — Un message confirme un retour réussi.

Scripts en ligne de commande

  • writeoff_debts.pl — Les options --added_after et --patron_category précisent les dettes à annuler.

  • runreport.pl — On peut choisir le caractère de délimitation des champs de l'export CSV.

  • sitemap.pl — L'option --where limite le sitemap du site aux notices qui répondent à une condition SQL.

  • search_for_data_inconsistencies.pl — Le script d'audit compare la structure de la base de données à celle attendue par Koha.

  • borrowers-force-messaging-defaults.pl — Le script peut se limiter aux adhérents d'un site ou à un type de message.

API REST

  • Prêts — Un point d'accès permet de prêter un exemplaire à un adhérent.

  • Adhérents — Un adhérent créé par l'API peut recevoir la notification de bienvenue.

  • Nouveaux points d'accès — Types de document, recherche des notices par n'importe quel champ de biblioitems.

Préférences système

Nouvelles préférences :

  • AcquisitionsDefaultEMailAddress
  • AcquisitionsDefaultReplyTo
  • AdditionalFieldsInZ3950ResultAuthSearch
  • AuthorLinkSortBy
  • AuthorLinkSortOrder
  • AutomaticCheckinAutoFill
  • CalculateFundValuesIncludingTax
  • CancelOrdersInClosedBaskets
  • ChildNeedsGuarantor
  • CookieConsent
  • CookieConsentedJS
  • DefaultAuthorityTab
  • DefaultPatronSearchMethod
  • EmailPatronWhenHoldIsPlaced
  • ForceLibrarySelection
  • ILLModuleDisclaimerByType
  • ILLPartnerCode
  • intranetReadingHistoryHolds
  • LoadCheckoutsTableDelay
  • OpacTrustedCheckout
  • PreservationModule
  • PreservationNotForLoanDefaultTrainIn
  • PreservationNotForLoanWaitingListIn
  • RedirectGuaranteeEmail
  • SCOLoadCheckoutsByDefault
  • SIP2AddOpacMessagesToScreenMessage
  • SerialsDefaultEMailAddress
  • SerialsDefaultReplyTo
  • SerialsSearchResultsLimit
  • TrackLastPatronActivityTriggers (anciennement TrackLastPatronActivity)
  • UpdateItemLocationOnCheckout
  • showLastPatronCount

Préférences supprimées :

  • AllowOfflineCirculation
  • OPACResultsSidebar, OpacMaintenanceNotice, OpacSuppressionMessage, PatronSelfRegistrationAdditionalInstructions, SCOMainUserBlock, SelfCheckHelpMessage et SelfCheckInMainUserBlock (remplacées par des personnalisations HTML)
  • RecordedBooksClientSecret, RecordedBooksDomain et RecordedBooksLibraryID
  • TrackLastPatronActivity (remplacée par TrackLastPatronActivityTriggers)