Koha 22.11

La version 22.11 de Koha est une version majeure. La couverture fonctionnelle de Koha se trouve considérablement étendue. Pour une bibliothèque ou un centre de documentation, Koha devient la plateforme unique et unifiée de gestion de toutes ses ressources, aussi bien traditionnelles qu'électroniques. Au menu : un module ERM fonctionnellement et visuellement très réussi, des mécanismes d'authentification modernes et intégrés au système d'information des établissements, un relooking très attendu de l'interface pro, et bien plus.

Nouvelles fonctionnalités

Authentification à deux facteurs obligatoire

La sécurité en ligne est une question prioritaire. Une couche de protection n'est pas suffisante. Un mot de passe, même complexe, peut toujours être piraté. Un niveau de sécurité supplémentaire consiste à utiliser une authentification à deux facteurs, ou en deux étapes. La première étape de l'authentification reste le mot passe. Une deuxième étape renforce la vérification de votre identité en demandant un code à usage unique. On utilise une application pour générer ce mot de passe, par exemple Google Authenticator ou OTP Auth.

La version de 22.05 de Koha a introduit un mécanisme d'authentification en deux étapes pour l'interface pro. On l'active avec la préférence TwoFactorAuthentication. Puis sur la fiche d'un adhérent utilisateur professionnel, dans le menu Plus, une nouvelle option apparaît qui permet de gérer l'authentification renforcée. Quand on l'active, un QR code est affiché. On l'utilise pour enregistrer Koha dans son application d'authentification à deux facteurs.

La version 22.11 ajoute la possibilité de rendre obligatoire l'authentification à deux facteurs. Avec cette option supplémentaire de la préférence TwoFactorAuthentication, il n'est plus nécessaire de passer par le module Adhérents pour enregistrer son application d'authentification avec l'utilisateur professionnel. L'utilisateur sera invité à le faire lui-même lors de sa première connexion. Cette option s'applique à tous les utilisateurs professionnels.

Par ailleurs, pour les établissements qui ne souhaitent pas utiliser une application de génération de mot de passe à usage unique (Google Authenticator ou OTP Auth), il est aussi possible désormais d'envoyer le code de vérification par email. Une nouvelle notification est utilisée à cet effet : 2FA_OTP_TOKEN.

Protocoles de fédération d'identité OAuth2/OIDC

Avec la multiplication des applications web, il devient essentiel de proposer des mécanismes d'authentification unifiés et partagés. Le but visé est d'éviter à l'usager d'avoir à s'authentifier à de multiples reprises. Il se connecte à une application et n'a pas plus à le faire par la suite. La fédération d'identité est un moyen d'atteindre cet objectif. Ce modèle d'authentification est mis en œuvre au moyen de protocoles standardisés comme OAuth2 et OpenID Connect (OIDC). Ces protocoles permettent d'échanger des jetons d'identité entre d'un côté les fournisseurs d'identités (penser à FranceConnect) et de l'autre des fournisseurs de services (penser, même si ce n'est pas agréable, à Ameli ou impot.gouv).

Pour aller plus loin sur ce sujet, un article sur Renater : https://services.renater.fr/federation/introduction/index

À partir de cette version de Koha, on peut lier son SIGB à des fournisseurs d'identités qui comprennent le protocole OAuth2 ou OIDC. Ces fournisseurs sont ensuite utilisés au moment de l'authentification à l'interface pro de Koha ou à l'OPAC. L'implémentation de cette fonctionnalité a été réalisée de façon à permette d'intégrer d'autres protocoles à l'avenir. Aller en Administration > Fournisseurs d'identité.

Exemple d'utilisation — Votre établissement utilise les outils en ligne de Microsoft ou de Google. Vos usagers sont connectés à ces services. Koha peut être configuré pour récupérer automatiquement les informations de connexion à ces services.

Relooking de l'interface pro

Les utilisateurs professionnels de Koha méritaient que l'interface, elle-même professionnelle, de leur SIGB préféré soient modernisée. C'est chose faite avec cette nouvelle version de Koha. Les dégradés de gris restent au programme, désormais soulignés d'un vers discret très Koha, ponctué ici et là de boutons jaunes telles une invitation au clic. Le nouveau design tout en arrondis et en sobriété accélère l'accès aux fonctions du logiciel et améliore la visibilité des contenus de pages même les plus riches. Globalement, l'affichage gagne en lisibilité, en compacité et en usabilité.

ERM / Gestion des ressources électroniques

Un module ERM complet a été intégré à Koha. Il permet de gérer le cycle de vie des ressources électroniques de tout type d'établissement, du petit centre de documentation à la grande bibliothèque universitaire. Grâce à son nouveau module ERM, Koha devient une plateforme complète de gestion de toutes les ressources d'une bibliothèque, les ressources traditionnelles aussi bien que les ressources électroniques.

L'offre de ressources électroniques des bibliothèques et des centres de documentation va grandissante d'année en année. Ce sont les revues électroniques, les eBooks, les médias en streaming, les bases de données, les logiciels, etc. La gestion de ces ressources ou ERM en anglais (Electronic Resource Management) est une part importante des tâches des bibliothécaires et des documentalistes. Les actions associées ces ressources couvrent leur acquisition, la gestion des droits d'accès et les accès eux-mêmes, leur entretien en état de fonctionnement, le suivi de leur usage.

Aussi le module ERM de Koha comprend-t-il les composants suivants :

• Contrat — Les contrats passés à des fournisseurs pour l'acquisition de ressources électroniques.

• eHoldings — D'ores et déjà, le module ERM peut se connecter à la base de connaissances HoldingIQ d'EBSCO. D'autres bases de connaissances seront intégrées à l'avenir : GOKb (USA/Global), bacon (France) et KB+ (Royaume-Uni). Ou encore le support des fichiers KBart.

• Licences — Stocke des informations sur les licences d'utilisation des ressources ou les fichiers des documents électroniques. On peut importer directement des fichiers ONIX-PL.

• Acquisitions — Les éléments précédents sont reliés au module Acquisitions de Koha au moyen du vendeur. Le vendeur du module Acquisitions doit se comprendre dans un sens étendu. Pour les ressources électroniques, il s'agit plutôt d'organisations, de plateformes de négociation, de consortium, de libraires, d'éditeurs, etc. La commande des ressources électroniques est géré directement dans le module Acquisitions.

• Statistiques — Les statistiques d'usage des ressources sont gérés avec SUSHI COUNTER.

Trois préférences ont été ajoutées à un nouvel onglet ERM des préférences système :

• ERMModule pour activer le module.
• ERMProviders : sélection des fournisseurs. Deux options : local ou EBSCO.
• ERMProviderEbscoCustomerID et ERMProviderEbscoApiKey pour la connexion aux services web d'EBSCO.

Onze listes de valeurs autorisées permettent de configurer finement le module ERM :

• ERM_AGREEMENT_STATUS : Statut du contrat. Par exemple, Actif, Clos ou En négociation. Ne pas changer les codes systèmes active et closed.
• ERM_AGREEMENT_CLOSURE_REASON : Raison de la clôture d'un contrat. Par exemple, Annulé ou Expiré.
• ERM_AGREEMENT_RENEWAL_PRIORITY : Priorité de renouvellement du contrat. Par exemple, Renouveler, À évaluer et Annuler.
• ERM_USER_ROLES : Rôle de l'utilisateur associé à un contrat. Par exemple, Bibliothécaire ou Spécialise du domaine X.
• ERM_AGREEMENT_LICENSE_LOCATION
• ERM_AGREEMENT_LICENSE_STATUS
• ERM_LICENSE_STATUS
• ERM_LICENSE_TYPE
• ERM_PACKAGE_CONTENT_TYPE
• ERM_PACKAGE_TYPE
• ERM_TITLE_PUBLICATION_TYPE

Les informations relatives à la gestion des ressources électoniques sont stockées dans onze nouvelles tables de la base de données MySQL :

• erm_agreements
• erm_agreement_licenses
• erm_agreement_periods
• erm_agreement_relationships
• erm_documents
• erm_eholdings_packages
• erm_eholdings_packages_agreements
• erm_eholdings_resources
• erm_eholdings_titles
• erm_licenses
• erm_user_roles

Boîtes d'exemplaires

Cette nouvelle fonctionnalité permet de créer des boîtes d'exemplaires qui sont ensuite empruntables en bloc. La nature de ces boîtes d'exemplaires varie d'une bibliothèque à l'autre. Il peut s'agir effectivement de boîtes, mais ce peut être aussi bien des cartons, des boîtes d'archives, de chemises, etc. Les exemplaires contenus dans ces boîtes sont destinés à être diffusés auprès de publics ciblés. Pour la bibliothèque d'un conservatoire de musique, cela peut être un ensemble de partitions diffusées de façon groupée à l'occasion d'une représentation. Etc. On crée une notice bibliographique de niveau recueil factice (position 7 de l'étiquette), à laquelle on ajoute comme d'habitude des exemplaires. Ces exemplaires seront les contenant auxquels on ajoute ensuite des sélections d'exemplaires au moyen de leurs codes à barres. Ces exemplaires sont marqués comme non empruntables dans leur notice d'origine.

Les boîtes d'exemplaires sont prêtées en bloc, avec leur code à barres, en suivant la procédure habituelle de prêt. En revanche, au moment du retour, une étape de vérification est ajoutée. Les codes à barres des exemplaires du paquet doivent être scannés. Les exemplaires manquants sont identifiés et marqués comme tel dans le champ Perdu. Les exemplaires surnuméraires, hors paquet, sont signalés afin que l'opérateur de prêt les mette de côté pour un traitement ultérieur.

• CONFIGURER — Vous pouvez décider de créer un type de document spécifique pour les boîtes d'exemplaires. Cela permet de les distinguer et de leur assigner des règles de circulation spécifiques. Les paquets d'exemplaires utilisent deux nouvelles préférences systèmes :

  • BundleNotLoanValue : Quand un exemplaire est ajouté à un paquet, il est basculé au statut non empruntable en copiant la valeur de cette préférence dans le champ items.notforloan (statut de l'exemplaire). Vérifier les valeurs autorisées correspondantes.
  • BundleLostValue : Au retour d'un paquet, les exemplaires non scannés sont marqués comme perdus en recopiant la valeur de cette préférence dans items.itemlost (champ Perdu).

• RECUEIL FACTICE — La fonctionnalité de gestion des boîtes d'exemplaires est proposée uniquement pour les notices de niveau bibliographique Recueil factice. On crée une notice de ce type en plaçant la valeur c en position 7 de l'étiquette de la notice. La notice est renseignée de façon à informer les usagers de la nature et du contenu de la boîte d'exemplaires. Un ou plusieurs exemplaires sont créés. Chacun de ces exemplaires est une boîte dans laquelle on place ensuite des exemplaires.

• REMPLIR — Dans le tableau des exemplaires de la notice de recueil factice, une nouvelle option est proposée pour chaque exemplaire : Gérer boîte. En cliquant sur ce bouton, une sous-section est affichée sous l'exemplaire. Les exemplaires de la boîte sont affichés. On ajoute et on supprime des exemplaires au moyen de leurs codes à barres. On peut également supprimer des exemplaires d'une boîte en scannant leurs codes à barres en Circulation > Retour. Les exemplaires ajoutés ont leur champs statut qui passe à BundleNotLoanValue. Les exemplaires ajoutés sont toujours attachés à leur notice d'origine. Dans le pavé d'affichage des exemplaires de la notice d'origine, un lien est affiché qui permet d'aller directement sur la boîte d'exemplaires.

• PRÊTER — On prête une boîte d'exemplaires en scannant son code à barres comme on prête un exemplaire unique. C'est le code à barres de la boîte qui est utilisé. Si on essaie d'utiliser le code à barres d'un exemplaire qu'elle contient, un message d'erreur est affiché. Le prêt de la boîte est visible sur la notice biblio et sur la fiche du lecteur à qui elle a été prêtée.

• RENDRE — Le retour d'une boîte se fait comme le retour d'un exemplaire unique. Toutefois il y a en plus une étape de vérification du contenu de la boîte. Une liste des exemplaires de la boîte est affichée. On doit scanner un à un les codes à barres des exemplaires. Si tous les exemplaires de la boîte ont été scannés, un message est affiché qui indique que le retour est complet. Si des exemplaires sont manquants, un message indique que le contenu de la boîte a changé. Deux options sont proposées : voir le contenu modifié de la boîte ; voir la liste des exemplaires manquants. Les exemplaires manquants sont automatiquement retirés de la boîte et sont marqués comme manquant : champ Perdu passé à la valeur de la préférence BundleLostValue.

• RÉCLAMATIONS — Sur la fiche du lecteur, les exemplaires manquants sont affichés dans l'onglet Réclamations. Une option Résoudre permet de traiter la réclamation d'un exemplaire. On peut modifier le statut Perdu de l'exemplaire et sélectionner dans une liste (valeurs autorisées RETURN_CLAIM_RESOLUTION la raison de la résolution.

Modèles de saisie d'exemplaire

Avec cette fonctionnalité, les catalogueurs créent et partagent des modèles d'exemplaire. Un modèle est un ensemble de valeurs par défaut assignées à la grille de saisie d'un exemplaire. Les modèles sont appliqués exemplaire par exemplaire ou bien pour toute une session de catalogage. Un exemplaire peut être partagé avec les autres catalogueurs. Les utilisateurs ayant la permission manage_item_editor_templates peuvent modifier les modèles quel que soit leur créateur.

UTILISATION :

• En saisie d'un exemplaire, renseigner les champs que vous voulez réutiliser.
• En bas de page, cliquer sur le nouveau bouton Enregistrer le modèle.
• Vous pouvez créer un nouveau modèle ou bien remplacer un modèle existant. Vous décidez de partager ou non le modèle avec les autres catalogueurs.
• Vous cliquez sur Enregistrer.
• En haut de la grille de saisie d'un exemplaire, vous avez une barre de sélection des modèles. Une boîte de liste présente les modèles existants, les vôtres et ceux partagés par vos collègues.
• Vous pouvez appliquer un modèle, ponctuellement ou pour toute la session.
• Vous pouvez effacer le modèle pour remettre à vide la grille de saisie.
• Vous pouvez supprimer un modèle quand vous n'en avez plus besoin.

Regroupement des exemplaires d'une notice

Une nouvelle fonctionnalité de regroupement des exemplaires a été ajoutée à Koha. Elle répond aux besoins des bibliothèques qui rattachent à des notices bibliographiques un grand nombre d'exemplaires. C'est le cas par exemple des notices de périodiques pour lesquelles un exemplaire est créé pour chaque fascicule. Un regroupement par année ou par volume peut faciliter la gestion des exemplaires et les opérations de réservation.

On active le regroupement d'exemplaires avec la préférence EnableItemGroups. On peut ensuite gérer les regroupements si on dispose de la permission manage_item_groups. Sur la page de détail d'une notice bibliographique, dans le pavé des exemplaires, un nouvel onglet Groupes d'exemplaire est affiché. On y crée des groupes. On les nomme et on leur donne un ordre de priorité d'affichage. Dans l'onglet des exemplaires, quand on coche des exemplaires, deux nouvelles options sont affichées : Ajouter/déplacer vers un groupe et Supprimer du groupe. Une nouvelle colonne Groupe est affichée dans l'onglet des exemplaires. Elle contient le nom du groupe auquel appartient chaque exemplaire. Si on active la préférence EnableItemGroupHolds, les groupes sont affichés sur la page de réservation d'une notice bibliographique. La réservation peut être faite sur un groupe plutôt que sur l'ensemble des exemplaires ou sur un exemplaire spécifique. Les regroupements d'exemplaires sont gérés au moyen de deux nouvelles tables : item_groups et item_group_items.

Retraits sur rendez-vous

Un nouveau module de retrait de documents sur rendez-vous a été intégré à Koha. Les bibliothèques définissent des créneaux horaires pendant lesquels elles prennent des rendez-vous pour le retrait de documents ou de tout matériel. Chaque bibliothèque activant cette fonctionnalité peut décider le lier la prise de rendez-vous à la réservation. Un lecteur peut, au choix, prendre des rendez-vous uniquement s'il a des réservations mises de côté ou bien même en l'absence de réservations. Pour chaque jour de la semaine, plusieurs créneaux horaires peuvent être paramétrés. À l'intérieur des créneaux horaires, on définit des intervalles de retrait en minutes ainsi que le nombre de lecteurs que l'on pourra recevoir. On dira par exemple qu'on peut recevoir des lecteurs par intervalle de dix minutes et que, dans chacun de ces intervalles, on pourra accueillir un maximum de cinq lecteurs.

À l'OPAC, les lecteurs peuvent prendre eux-mêmes des rendez-vous. En PRO, les bibliothécaires gèrent les rendez-vous dans Circulation > Retraits sur rendez-vous. Un bibliothécaire peut prendre des rendez-vous pour les lecteurs. Des onglets présentent les différents étapes d'avancement des rendez-vous : planifié, planifié et validé, lecteur arrivé, livré.

Éléments de configuration :

• Préférence CurbsidePickup pour activer la fonctionnalité.
• Permissions :
  • parameters.manage_curbside_pickups pour paramétrer la fonctionnalité en Administration.
  • circulate.manage_curbside_pickups pour utiliser la fonctionnalité dans le module Circulation
• Tables :
  • curbside_pickup_policy : les politiques de retrait par bibliothèque.
  • curbside_pickup_opening_slots : les créneaux horaires de retrait.
• Notification NEW_CURBSIDE_PICKUP : Texte de l'email envoyé au lecteur pour l'avertir de la disponibilité d'un retrait ainsi que son créneau horaire.

Garants pour tout type de lecteur

Koha permet d'associer un lecteur à un garant. Ainsi certaines réclamations peuvent être adressées au garant plutôt qu'au lecteur lui-même. Jusqu'à présent, ces associations n'étaient possibles qu'entre certains types de catégorie d'adhérent : adute/enfant et collectivité/professionnel. Il est désormais possible de paramétrer toutes les catégories pour que leurs adhérents puissent être liés à un garant : par exemple, un adulte vers une collectivité ou un autre adulte. C'est en Administation > Catégories d'adhérent, sur la fiche d'une catégorie qu'une nouvelle option est proposée qui permet de décider si ses adhérents peuvent être garantis ou non.

Suspensions paramétrables

Les lecteurs peuvent être suspendus dans Koha. Jusqu'à présent, les suspensions étaient codées en dur, c.-à-d. qu'il n'existait que quatre motifs de suspensions codés dans le champ borrower_debarments.type : SUSPENSION, OVERDUES, MANUAL, DISCHARGE. Désormais, les suspensions non systèmes (MANUAL) peuvent être étendues et rendues paramétrables en activant la préférence système PatronRestrictionTypes. En allant en Administration > Suspensions des adhérents, on voit la liste des types de suspensions définis et on peut ajouter de nouveaux types. Ils sont enregistrés dans la nouvelle table debarment_types. Au moment, de la suspension manuelle d'un adhérent, les types de suspension ajoutés sont proposés dans une boîte de liste.

Gestion de contenu (CMS) intégrée

Sur le modèle des nouvelles de l'OPAC, il est possible d'ajouter des pages à Koha qu'on décide ensuite d'afficher à l'OPAC ou à l'interface professionnelle. Accessible dans Outils > Pages. L'affichage des pages est obtenu au moyen des URL suivantes :

• /cgi-bin/koha/opac-page.pl?page_id=ID_PAGE
• /cgi-bin/koha/tools/page.pl?page_id=ID_PAGE

Filtres de recherche paramétrables

Cette nouvelle fonctionnalité permet de proposer en résultat des recherches à l'OPAC et en pro des filtres paramétrables. C'est par exemple pour une bibliothèque de lecture publique un filtre pour restreindre le résultat aux documents en gros caractères ou aux ressources destinées au jeune public. Pour une bibliothèque spécialisée, c'est un filtre pour ne présenter que les documents numériques. Etc.

On active cette fonctionnalité avec la préférence SavedSearchFilters. En résultat de toute recherche à l'interface pro, une nouvelle option est proposée qui permet d'enregistrer l'équation de recherche, de la nommer et de spécifier son usage, OPAC et/ou pro. Les filtres de recherche sont enregistrés dans une nouvelle table search_filters. On les gère en Administration > Filtres de recherche quand on dispose de la permission manage_search_filters. Les filtres sont présentés en résultat des recherches dans le pavé des facettes.

Améliorations

Acquisitions

• Date de livraison prévue — La date de livraison prévue des commandes est calculée automatiquement. Un panier est associé à un fournisseur. Dans la fiche du fournisseur, un délai de livraison en jours est spécifié. Quand un panier de commandes est fermé, toutes les commandes ont automatiqument une date de livraison prévue qui est fixée à la date de fermeture du panier + le nombre de jours du délai de livraison du fournisseur.

  Mais il est désormais possible de spécifier sur chaque ligne de commande d'un panier une date de livraison prévue spécifique. Cette date vient remplacer la date globale calculée automatiquement. Si la date de livraison de la ligne de commande est laisée vide, c'est la calcul automotique qui est calculée.

• Changement du budget après réception — Il peut être nécessaire de réallouer une commande à un autre budget que celui qui avait été choisi au moment de passer la commande. On peut le faire désormais depuis la facture.

• Affichage amélioré des titres — Partout dans le module Acquisitions, le titre des documents commandés étaient affichés, mais seulement le titre principal (200$a). Désormais d'autres élements du titre sont aussi affichés : type de document (200$b), sous-titre (200$e), nom de partie (200$h) et numéro de partie (200$i).

• Recherche par ISSN — La possibilité de rechercher par ISSN a été ajoutée à la page de recherche avancée. La préférence SearchWithISSNVariations est prise en compte pour que les tirets soient pris en compte ou non.

• Champs supplémentaires pour les factures — Pour les bibliothèques qui veulent synchroniser leurs factures de commandes Koha avec le système de gestion comptable de leur établissement, Koha propose maintenant l'option d'ajouter des champs aux factures. Aller en Administration > Gérer les sous-champs supplémentaires > Factures (aqinvoices).

• Note privée pour les suggestions — Un champ de note privée a été ajouté à la table des suggestions : suggestions.privatenote. Si un bibliothécaire crée une suggestion à l'interface pro et qu'il affecte cette suggestion à un lecteur, la note privée de la suggestion sera visible à l'interface pro, mais le lecteur ne la verra pas à l'OPAC.

• Limitation des suggestions d'achat — Les lecteurs peuvent faire des suggestions d'achat à l'OPAC si la préférence suggestion est activée. Une nouvelle préférence suggestionPatronCategoryExceptions permet de spécifier les catégories d'adhérents qui ne pourront pas faire de suggestions à l'OPAC.

• Type de fournisseur — Un champ a été ajouté à la table des fournisseurs afin de permettre leur catégorisation : aqbooksellers.type.

Circulation

• Colonne Déclarer rendu — La fonctionnalité Déclarer rendu permet de noter qu'un adhérent déclare avoir rendu un exemplaire signalé comme toujours emprunté dans Koha. Voir Préférences système > Circulation > Déclarés rendus. Une colonne a été ajouté au tableau des retards pour afficher cette information : Circulation > Retards.

Authentification

• Notification du changement de mot de passe — Quand le mot de passe d'un lecteur est modifié, on peut désormais demander à Koha d'envoyer automatiquement un email de notification au lecteur. On active la fonctionnalité avec la préférence NotifyPasswordChange. Le code la nouvelle notification est PASSWORD_CHANGE.

Catalogage

• 001 = biblionumber — Une nouvelle préférence autoControlNumber permet de renseigner automatiquement la zone 001 des notices bibliographiques avec le biblionumber des enregistrements quand elles sont créées.

• Date de suppression des exemplaires — Les exemplaires supprimés de Koha sont placés dans la table deleteditems. Un champ deleted_on a été ajouté à cette table afin de conserver la date à laquelle la suppression de chaque exemplaire a été faite. Jusqu'à présent, on pouvait toujours utiliser le champ timestamp pour cet usage, mais il y avait un risque de perte d'information si la table était mise à jour dans le cadre d'opérations de maintenance.

• Plugins Zones codées — Des plugins de catalogage ont été ajoutés pour les zones et sous-zones suivantes :

  Zone	Sous-zones
  146	b, c, d, e, f
  181	2, a, b, c
  182	2, a, b, c
  183	2, a
  283	2, a
  325	h, j

• Plugin PPN Sudoc — Pour les bibliothèques qui souhaitent se caller sur le Sudoc sans être déployé dans le Sudoc, on crée généralement dans les notices Unimarc une zone 009 pour y placer le PPN de la notice Sudoc correspondante. Un nouveau plugin unimarc_field_009_ppn.pl permet de remplir automatiquement la zone 009 en lançant des recherches dans le Sudoc à partir des données locales : ISBN (010$a), ISSN (011$a) ou EAN (073$a).

Circulation

• Catégorie d'adhérent dans statistics — La table des statistiques de circulation statistics contient le type d'exemplaire mais pas la catégorie d'adhérent. Cela oblige à faire des jointures sur d'autres tables à partir de l'identifiant du lecteur si l'on souhaite effectuer des regroupements sur la catégorie des lecteurs. Un champ statistics.categorycode a été ajouté afin de simplifier certaines requêtes statistiques.

• Volume dans l'historique de prêt — Dans le tableau d'affichage des l'historique des prêts, à l'OPAC et en PRO, un colonne a été ajoutée pour le champ Volume des exemplaires.

• Historique des renouvellements — Dans l'historique des prêts d'un lecteur affiché à l'interface PRO, un compteur des renouvellements est affiché. Si la journalisation des renouvellements est activée (préférence RenewalLog), une nouvelle option Voir est affichée à côté du compteur de renouvellement. En cliquant sur ce lien, une boîte modale s'ouvre qui affiche l'historique détaillé des renouvellements.

• Imprimer ticket paramétrable — La préférence système DisplayClearScreenButton permet d'afficher une icône d'impression d'un ticket sur la page des prêts. La préférence a été étendue pour proposer de choisir le ticket à utiliser, normal ou rapide, ISSUESLIP ou ISSUEQSLIP.

• Affichage du statut en retour — La préférence UpdateNotForLoanStatusOnCheckin permet de modifier le statut d'un exemplaire (items.notforloan) au moment du retour de l'exemplaire. Cette préférence a beaucoup été utilisée en période de Covid pour mettre les documents en quarantaine quand ils étaient rendus. L'usage de cette préférence a été étendue pour afficher la description de certains statuts au moment du retour. Par exemple, pendant qu'un exemplaire est en prêt, son statut est passé à 10 (Futur expo). UpdateNotForLoanStatusOnCheckin est modifié en ajoutant cette ligne : 10: ONLYMESSAGE. Le code ONLYMESSAGE instruit Koha que le retour des exemplaire qui ont un statut à 10 doit affiché la valeur autorisée correspondante, ici Futur expo.

• Affichage des rappels des lecteurs sur leur fiche — Depuis la version 22.05, Koha dispose d'une fonctionnalité de rappel de document. Les rappels d'un lecteur qui sont prêts pour le retrait sont désormais affichés sur la fiche du lecteur.

• Email de rappel — Les retards sont réclamés au moyen du script overdue_notice.pl qui suit les règles définies en Outils > Paramétrage des relances. Le paramètre du script frombranch permet de choisir l'adresse de l'email envoyé au lecteur entre deux options : item-issuebranch pour l'adresse de la bibliothèque où le prêt a été effectué ; item-homebranch pour l'adresse de la bibliothèque propriétaire de l'exemplaire. Jusqu'à présent ce choix était fait globalement au niveau des tâches planifiées du serveur. Désormais une nouvelle préférence OverdueNoticeFrom permet à l'administrateur fonctionnel de Koha de sélectionner l'adresse à utiliser.

Réservations

• Réaffectation auto des réservations mises de côt et expirées — On peut paramétrer Koha pour que les réservations mises de côté qui ont expiré soient automatiquement annulées : préférence ExpireReservesMaxPickUpDelay et script cancel_expired_holds.pl. Si on veut réaffecter l'exemplaire à une autre demande de réservation, il est nécessaire de faire manuellement un retour de l'exemplaire. Une nouvelle fonctionnalité permet d'identifier ce cas de figure et d'envoyer un email à un bibliothécaire pour qu'il fasse le nécessaire. On utilise deux nouvelles préférences et une nouvelle notification:

  • ExpireReservesAutoFill : pour activer la fonctionnalité.
  • ExpireReservesAutoFillEmail : email du bibliothécaire qui recevra la notification signalant que l'exemplaire a été réaffecté.
  • HOLD_CHANGED : la notification envoyée au bibliothécaire.

• Changement de la bibliothèque de retrait des réservations pas encore mises de côté — Un lecteur fait une réservation à l'OPAC. Il choisit une bibliothèque de retrait. Après quoi, il ne peut plus revenir sur ce choix. Une nouvelle préférence OPACAllowUserToChangeBranch autorise les lecteurs à modifier la bibliothèque de retrait de leurs réservation, tant qu'elles ne sont mises de côté, et ce à différentes étapes du traitement de la demande.

• Changement de la bibliothèque de retrait quand un exemplaire est en transit — Jusqu'à présent quand une réservation est affectée à un lecteur et que l'exemplaire est en transit vers la bibliothèque de retrait choisi, il n'est plus possible pour le lecteur de choisir une autre bibliothèque de retrait. Une nouvelle préférence OPACInTransitHoldPickupLocationChange permet au lecteur de changer de bibliothèque de retrait alors que l'exemplaire est en transit. Un nouveau transfert sera déclenché automatiquement.

• Annulation à l'OPAC des réservations mises de côté — Un lecteur réserve un document. Le document est mis de coté pour le lecteur. Il est en attente de retrait à une bibliothèque. À ce stade, jusqu'à présent, Koha ne permettait au lecteur d'annuler sa réservation, autrement qu'en contactant directement la bibliothèque. Désormais, on peut paramétrer Koha pour autoriser les lecteurs à annuler eux-mêmes à l'OPAC leurs réservations en attente.

  • PARAMÉTRAGE — En Administration > Règles de circulation, une nouvelle section Politique d'annulation des réservations mises de côté permet de définir si l'annulation est possible pour des combinaisons Catégorie d'adhérent/Type de document.

  • UTILISATION — À l'OPAC, le lecteur qui en a le droit peut annuler une réservation mise de côté. La demande d'annulation est placée dans une nouvelle table hold_cancellation_requests. En PRO, en Circulation > Réservations mises de côté, un nouvel onglet est affiché : Demandes d'annulation.

Lecteurs

• Pronoms lecteur — Sur la fiche d'un lecteur, un champ Pronoms a été ajouté: champ pronouns dans la table borrowers. Certaines bibliothèques pourront utiliser ce champ pour une meilleure prise en compte des problématiques de genre.

• Persistance des lecteurs sélectionnés — Le résultat d'une recherche de lecteurs est affiché dans un tableau. Si le résultat est important, le tableau est paginé. Jusqu'à présent quand on sélectionnait des lecteurs sur une page du tableau, puis qu'on se déplaçait sur une autre page, quand on revenait sur la page initiale la sélection de lecteurs était perdu. C'est plus le cas maintenant.

• Email de bienvenue pour les lecteurs inscrits via LDAP et Shiboleth — Quand un lecteur se connecte à Koha via LDAP ou Shiboleth, s'il n'existe pas dans Koha, sa fiche est créée (paramétrable). Une nouvelle option permet de déclencher l'envoi d'un email de bienvenue (notification WELCOME) à ces lecteurs. Le paramétrage se fait dans KOHA_CONF :

  <welcome>1</welcome>

Divers

• Réaffectation des listes quand leur propriétaire est supprimé — Quand un adhérent est supprimé, toutes ses listes sont supprimées. Deux nouvelles préférences permettent de choisir quoi faire des listes des adhérents que l'on supprime :

  • ListOwnershipUponPatronDeletion : soit supprimer ses listes soit les réaffecter à un autre adhérent.
  • ListOwnerDesignated : soit l'adhérent qui supprime le propriétaire des listes soit un adhérent dont on donne le borrowernumber.

• Réaffectation de listes publiques/partagées — Les bibliothécaires ayant les permissions nécessaires (edit_public_lists) peuvent désormais changer le propriétaire des listes publiques. À l'OPAC, le propriétaire d'une liste partagée peut transférer la propriété de la liste à un des lecteurs attachés à la liste.

• Notification des auto-inscriptions — Les lecteurs peuvent s'inscrire eux-mêmes à la bibliothèque via l'OPAC si la préférence PatronSelfRegistration est activée. Certaines bibliothèques qui utilisent cette fonctionnalité regrettent de ne pas pouvoir suivre les auto-inscriptions. C'est désormais possible. Avec la préférence EmailPatronRegistrations, on demande à Koha d'envoyer un email quand un lecteur s'inscrit. L'email utilise la nouvelle notification OPAC_REG. La préférence EmailPatronRegistrations permet de choisir à quelle adresse envoyer l'email: bibliothèque d'inscription du lecteur, administrateur de Koha (préférence KohaAdminEmailAddress), adresse définie dans la nouvelle préférence EmailAddressForPatronRegistrations.

• Informations multilingues sur les bibliothèques à l'OPAC — À l'OPAC, des informations relatives aux bibliothèques définies dans Koha sont affichées. Jusqu'à présent, on définissait un texte de présentation unique par bibliothèque en Administration > Tous les sites. Désormais, pour chaque bibliothèque, on peut définir un texte différent pour chaque langue installée sur son système. La langue sélectionnée à l'OPAC détermine la version du texte affichée.

• XSLT Autorités à l'OPAC — La vue du résultat d'une recherche d'autorités à l'OPAC est désormais contrôlée par une feuille de style XSLT comme pour les notices bibliographiques.

• Extension des hooks des plugins — Les hooks des plugins sont des événements qui déclenchent des actions traitées par les plugins Koha. De nouveaux hooks ont été ajoutés :

  • after_hold_action
  • after_account_action
  • after_recall_action

• Automates de prêt / déverrouillage — Quand un prêt est réalisé via un automate de prêt, l'étiquette RFID de l'exemplaire est déverrouillée. Or certaines bibliothèques ont des types de document pour lesquels ne sont autorisés que des prêts sur place. Un nouveau paramètre du fichier de configuration du Serveur SIP2 de Koha permet de spécifier les types de document dont les étiquettes ne doivent pas être déverrouillées : inhouse_item_types.

• Recherche dans une recherche — En PRO, après avoir fait une recherche, dans la page de résultat, une nouvelle boîte de recherche est proposée qui permet de lancer une nouvelle recherche dans le résultat de la première recherche.