Koha 16.05

-

La version 16.05 de Koha apporte au logiciel son lot d’améliorations et de nouvelles fonctionnalités. Certaines sont particulièrement remarquables et méritent qu’on les présente en détail.

Note importante : Le support d'Ubuntu 16.04 est en cours de finalisation. Cette version d'Ubtuntu propose MySQL en version 5.7 qui bloque l'installation et la mise à jour de la base de données de Koha.

Principales améliorations

EDIFACT en Acquisition

La norme EDIFACT (Electronic Data Interchange For Administration, Commerce and Transport) est une norme internationale d'échange de données électroniques. En adhérant à cette norme, des sociétés, des établissements distincts peuvent échanger électroniquement des documents tels que des bons de commande, des factures, etc. Le principe de fonctionnement d'EDIFACT dans Koha est le suivant.

Un devis fournisseur génère un panier d'acquision avec autant de lignes de commande qu'il y a de lignes dans le devis. À partir du panier précédent, ou de tout panier, l'utilisateur génère une commande EDIFACT qui est transférée au fournisseur. Le fournisseur émet une facture à l'envoi de chaque colis. Chacune d'entre elle devient une facture dans Koha. Chaque ligne de commande correpondant à une ligne de la facture est automatiquement marquée comme reçue.

Koha gère également la réponse aux messages envoyés par les fournisseurs au sujet des commandes passées. Cela comprend le simple accusé de réception de la commande, la modification de la commande en fonction de la disponibilité. L'annulation d'une commande par le fournisseur provoque l'annulation de la commande dans Koha. Les autres messages sont enregistrés avec la commande dans Koha. Les traitements associés aux messages des fournisseurs sont définis en Administration de Koha fournisseur par fournisseur.

L'EDIFACT peut fonctionner en mode tout-automatique. Cela correspond à un process dans lequel tout le travail de gestion des commandes est réalisé sur le site web du fournisseur. Un pseudo-devis est émis par le fournisseur qui génère toute la commande dans Koha sans intervention d'un opérateur.

Authentification via Google OAuth2

L'authentification dans Koha peut désormais être réalisée au moyen du protocole Google OAuth2. Il faut se rendre sur cloud.google.com > console, créer un projet, puis un "credidential" OAuth pour une application web : le faire pointer sur votreopac.bibliotheque.fr/cgi-bin/koha/svc/googleoauth2. Dans Koha, vous renseignez les deux préférences GoogleOAuth2ClientID et GoogleOAuth2ClientSecret.

http://opac.mabiblio.fr/cgi-bin/koha/svc/auth/googleopenidconnect

client ID: 685379627775-m3pjfknddk5oqhpsbr68kv10gpiuoq6c.apps.googleusercontent.com

client secret: 94w7boCejVh-f9HSWoY0XdPr

Améliorations

De nombreuse améliorations ont été apportées à l’interface professionnelle et à l’OPAC. Elles visent à simplifier le travail des bibliothécaires et des usagers. On ne peut pas lister ici toutes ces améliorations : il y en a bien trop. Elles proviennent des retours des utilisateurs eux-mêmes. Koha profite pleinement du dynamisme de sa communauté et de l’importance de la base des bibliothèques qui l’utilisent. Bien souvent, ce sont des points de détail, mais des détails qui comptent pour les bibliothécaires et qui font toute la différence au quotidien : position d’un lien sur un écran, enchaînement de pages, etc., toutes choses qui font gagner du temps, qui simplifient significativement l’utilisation du logiciel.

Parmi ces améliorations, on peut citer :

Limitation des types de document en suggestion d’achat

À l’OPAC, lorsqu’ils font une suggestion d’achat, les lecteurs peuvent choisir un type de document. Jusqu’à présent, il s’agissait des types de document Koha définis en Administration. Désormais la liste des types de document peut être différente. Elle est fournie par la liste de valeurs autorisées SUGGEST_FORMAT. En montée de version, cette liste est remplie automatiquement avec les types de document existants.

Dédoublonnage des notices d’un lot de notices ajouté à un panier

Jusqu’à présent, dans le module Acquisition, quand on ajoutait un lot de notices à un panier, s’il n’y avait qu’une notice dans le lot, un test de dédoublonnage était effectué : si un doublon était trouvé, il était proposé de créer une nouvelle commande, d’ajouter une ligne de commande, ou d’ignorer la notice. En revanche, quand le lot contenait plusieurs notices, aucun dédoublonnage n’était effectué.

Désormais, un lot de plusieurs notices est également dédoublonné quand il est ajouté à un panier. Les doublons trouvés sont ignorés et des liens vers les doublons sont affichés dans une zone d’avertissement.

Ajout d’une colonne Date d’expédition dans le tableau des factures

Dans le tableau qui présente le résultat d’une recherche de factures, une colonne «Date d’expédition» a été ajoutée.

Envoi d’un email quand une suggestion est associée à un poste budgétaire

Quand une suggestion d’achat est associée à un poste budgétaire, un courriel peut être envoyé automatiquement au propriétaire du poste budgétaire. Il faut que le poste budgétaire ait un propriétaire ayant une adresse de courriel. Il faut que la notification TO_PROCESS soit définie. Il faut enfin programmer le script (cronjob) notice_unprocessed_suggestions.pl.

Affichage du vendeur dans l’onglet Acquisition d’une notice

Avec la préférence système AcquisitionDetails, un onglet est affiché sur la page de détail d’une notice biblio dans l’interface professionnelle. Dans cet onglet, des informations provenant du module Acquisition sont affichées relatives à la commande de la notice bibliographique. Le nom du vendeur de la commande a été ajouté.

Duplication d’un exemplaire existant

Jusqu’à présent, on pouvait seulement dupliquer un exemplaire après avoir ajouté un exemplaire. On peut désormais revenir sur la liste des exemplaires d’une notice, sélectionner un exemplaire et le dupliquer.

Fusion de plusieurs notices bibliographiques

L’outil de fusion de notices bibliographiques a été amélioré afin de permettre la fusion de plus de deux notices.

Amélioration de l’export aux formats RIS et BibTex

Deux nouvelles préférences systèmes ont été ajoutées afin de rendre configurable l’export aux formats RIS et BibTex. La préférence RisExportAdditionalFields contient la liste des champs à exporter en plus des champs standards. Par exemple:

TY: 942$c LC: 010$a

Idem pour l’export BibText avec la préférence BibtexExportAdditionalFields.

Amélioration du plugin Unimarc_field_4XX

Le plugin associé aux champs de lien 461/463 affiche en résultât de recherche des infos supplémentaires sur le titre : sous-titre, volume, titre de partie et numéro de partie. Le titre est maintenant cliquable également.

Configurabilité de la table des exemplaires en ajout d’exemplaires

Dans le module de Catalogage, en ajout/modification d’exemplaires, une table affiche tous les exemplaires de la notice. Les colonnes de cette table sont désormais configurables en Administration > Configuration des colonnes.

Blocage du renouvellement

Le renouvellement d’un exemplaire peut être bloqué si l’emprunteur est suspendu ou si l’emprunteur a des retards. Deux nouvelles préférences systèmes contrôlent ces blocages : RestrictionBlockRenewing permet de demander à ce que tout renouvellement soit bloqué si l’emprunteur est suspendu.

OverduesBlockRenewing permet de bloquer le prêt de tout document si le lecteur à un exemplaire en retard, ou bien seulement de bloquer le renouvellement des retards.

Ajout d’une nouvelle option en confirmation d’un prêt d’une réservation

Quand un document qui est réservé par un lecteur est prêté à un autre lecteur, une boîte de dialogue apparaît demandant de confirmer le prêt et signalant qu’un autre lecteur l’a réservé. On était jusque-là invité à confirmer le prêt ou à l’annuler. Une troisième option est désormais proposée : Ne pas prêter et imprimer un ticket.

Affichage de la date d’expiration des réservations en circulation

Avec la préférence système ReservesMaxPickUpDelay, il est possible de définir combien de temps une réservation mise de côté reste attribuée à un lecteur. La date d’expiration des réservations est désormais affichée en tenant compte de la préférence système.

Amélioration des règles des amendes

Des amendes peuvent être appliquées pour de retards. On définit une période de retard (par exemple 7 signifie qu’une amende est appliquée tous les sept jours). Jusqu’à présent l’amende était appliquée à la fin de la période de retard (donc pour une période de sept jours, l’amende n’était pas appliquée entre 1 et 6 jours de retard). Un nouveau paramètre de la matrice des règles de circulation permet de choisir si l’amende s’applique en début ou en fin de période.

Quotas de prêts sur site

Les prêts sur site peuvent désormais être traités de façon spécifique. La préférence système ConsiderOnSiteCheckoutsAsNormalCheckouts permet d’activer un mode dans lequel les quotas de prêts sur site sont contrôlés par un nouveau paramètre de la matrice des règles de circulation : Prêts sur site autorisés.

Paiements des amendes en une fois

Dans la fenêtre de circulation, les amendes d’un emprunteur sont affichés. Devant chaque amende, il y a un lien pour la payer. Il y a désormais, en plus, un nouveau lien qui permet de payer toutes les amendes en une fois.

Script koha-mysql

Le script koha-mysql est disponible dans les installations «paquets Debian» de Koha. Il permet d’interagir avec la base de données MySQL en ligne de commande. Le script a été amélioré afin de passer tout paramètre au client MySQL standard (la commande mysql).

Affichage de l’auteur d’une annonce

Les annonces ne sont plus anonymes. L’auteur d’une annonce est automatiquement enregistré. Une nouvelle préférence système NewsAuthorDisplay permet en plus d’activer ou non l’affichage des auteurs des anonces.

Ajout d’un nouveau format de date

Un nouveau format de date a été ajouté à la préférence système dateformat : dd.mm.yyyy.

Permissions traduisibles

Les libellés des permissions (le texte en clair) étaient jusqu’à présent stockés directement dans des enregistrements de la base de données. Si bien que la traduction de ces textes posaient toutes sortes de problème. Un nouveau mécanisme a été ajouté à Koha qui permet de rendre les libellés des permissions traduisibles comme tous les autres les textes de l’interface de Koha.

Réorganisation de l’interface du Créateur d’étiquettes

Les éléments de l’interface homme-machine du Créateur d’étiquettes ont été réorganisés pour faciliter l’utilisation de l’outil.

Amélioration du Créateur de cartes d’adhérent

La suppression des adhérents dans les lots de cartes d’adhérent a été simplifié.

Amélioration du support RDA du format MARC21

Divers améliorations ont été apportées aux feuilles XSL d’affichage des notices MARC21 pour améliorer le support du format RDA en MARC21.

Lettres de réclamation aux formats html/csv/ods + email

Le script de génération des lettres de réclamation gather_print_notices.pl a été étendu. Il permet désormais de produire un résultat en html, csv et ods (OpenOffice). Les formats séparés (csv/ods) sont désormais pilotés par «notification», c.-à-d. qu’on peut paramétrer une notification qui extrait exactement les informations souhaitées de la base de données. Un nouveau paramètre –email a été ajouté au script. Il permet d’envoyer par courriel le fichier résultat du traitement des réclamations. On peut ainsi par exemple générer un fichier HTML qu’on envoie ensuite à un administrateur qui se chargera de l’imprimer, ou bien c’est un fichier ODS qu’on envoie à une personne qui l’utilisera dans des opérations de publipostage.

Retards imprimés directement depuis la fiche lecteur

Quand on est sur la fiche d’un lecteur qui a des retards, on peut désormais imprimer directement un tiquet de tous ses prêts en retard.

Paramétrage des dates dans les notifications

Dans les notifications, les dates sont affichées/imprimées telles qu’elles se trouvent dans la base de données. Cela signifie que pour certaines (date de création d’une notice par exemple), l’heure est également affichée. Une nouvelle syntaxe du langage de formatage des notifications permet de spécifier qu’on ne veut que la date, sans l’heure. Par exemple: <<biblio.timestamp | dateonly>>.

Ajout des infos bibliothèque sur les quitus

Les lettres de quitus des lecteurs utilisent la notification DISCHARGE. Cette notification peut désormais contenir des champs spécifiant la bibliothèque d’appartenance du lecteur: <>, etc.

Regroupement à l’OPAC de types de document

Le formulaire avancé de l’OPAC présente tous les types de document définis dans son installation de Koha. Bien souvent des types de documents sont définis pour granulariser les règles de circulation : par exemple, LIV ET LIVC pour distinguer des livres empruntables plus ou moins longtemps. Une nouvelle fonctionnalité permet de regrouper sous un unique intitulé plusieurs types de document.

Une liste de valeurs autorisée ITEMTYPECAT doit être définie. Quelques valeurs sont ajoutées à cette liste : par exemple LIVRE pour regrouper les types de document LIV et LIVC. Ensuite, en définition des types de document, on rappelle les types que l’on souhaite regrouper. On les rattache à la catégorie de regroupement et on peut également choisir de les cacher complètement à l’OPAC.

Choix de l’emplacement à l’OPAC du sélecteur de langue

Une nouvelle préférence système OpacLangSelectorMode permet de choisir à quel emplacement afficher à l’OPAC le sélecteur de langue. Après une montée de version, rien ne change : le sélecteur de langue est affiché en bas de page. On peut le modifier pour l’afficher en haut de page, en bas de page, ou bien les deux.

Sexe des adhérents «non spécifié»

Le sexe des adhérents puvait être : Feminin, Masculin ou N/D (pour non disponible). N/D a été renommé «non spécifié» parce que c’est plus respectueux.

Validation des adresses emai des lecteurs

En saisie de la fiche d’un lecteur, un avertissement est affiché quand les adresses de courriel saisies ne sont pas valide.

Courriel de notification d’expiration de l’inscription des adhérents

Un courriel peut être envoyé aux lecteurs dont la carte de bibliothèque est sur le point d’expirer.

Une nouvelle préférence système MemExpDayNotice permet de définir combien de de jours avant expiration de la carte la notification doit être envoyée. Un nouveau script membership_expiry.pl doit être lancé régulièrement (crontab). Il se sert de la préférence système pour déterminer les lecteurs auxquel le courriel de notification doit être envoyé.

Limitation des demandes de modification d’adhérents par site

À l’OPAC, les lecteurs peuvent faire des demandes de modification de leur fiche lecteur. Jusqu’à présent, les bibliothècaires voyaient dans le module professionnelles toutes ces demandes. Désormais, il est possible de limiter les demandes affichées à celles effectuées par les adhérents qui appartiennent au même site que le bibliothécaire.

Les utilisateurs super-bibliothécaires continuent de voir toutes les demandes. Pour les autres, cette fonctionnalité est pilotée par la préférence système existante IndependentBranches et une nouvelle préférence système IndependentBranchesPatronModifications. La limitation aux suggestions de la bibliothèque de l’utilisateur est effective si la première préférence est activée ou si la seconde l’est également.

Affichage de l’heure sur l’historique des prêts

Sur la fiche d’un lecteur, dans l’onglet Historique des prêts, l’heure du prêt est affichée en plus de la date.

Frais d’inscription quand changement de catégorie

Jusqu’à présent, quand un lecteur change de catégorie en cours d’inscription, de nouveaux frais d’inscription lui sont facturés. Une nouvelle préférence système FeeOnChangePatronCategory permet de choisir si de tels frais doivent être appliqués ou non.

Affichage date d’expiration des réservations

La date d’expiration des réservations est désormais affichée partout où c’est nécessaire : dans le module de circulation et en affichage de la fiche d’un lecteur.

Quitus multiples

Un seul quitus pouvait être fourni à un lecteur. Désormais, il est possible de définir plusieurs quitus pour un lecteur, ainsi que de conserver et d’afficher l’historique des quitus fournis.

Journal des rapports enregistrés

Les actions effectuées sur les rapports enregistrés peuvent être journalisées. Une nouvelle préférence système ReportsLog doit être activée.

Recherche ccl sur l’index itemnumber

L’index Zebra itemnumber existait mais n’était pas fonctionnel. Désormais une recherche ccl sur l’idenfiant interne d’un exemplaire fonctionne. Par exemple : itemnumber:10.

Indexation du champ MARC21-RDA 264

Le nouveau champ MARC21-RDA 264 est indexé comme le champ 260.

Extension de la configuration des index Zebra

Les index Zebra sont définis dans deux fichiers de configuration au format XML, respectivement pour les notices bibliographiques et pour les autorités. La syntaxe de ces fichiers a été étendues. Il est possible désormais de définir des index conditionnelles. Par exemple, si un indicateur contient telle valeur, l’index est alimenté.

Index ISBN et ISSN pour le MARC21

Les index ISBN et ISSN des catalogues MARC21 ont été étendues pour indexer les formes rejetées ou douteuses de ces identifiants.

Date de publication alternative pour les fascicules de périodique

La date de publication des fascicules s’affiche au format système défini dans Koha, par exemple jj/mm/aaaa. Un nouveau champ a été ajouté aux fasicules pour, si nécessaire, donner une forme textuelle simplifiée de la date de publication. On peut ainsi par exemple pour une date de publication «10/01/2016» afficher plutôt «Janvier 2016» si on renseigne ce nouveau champ.

Dates d’expiration de périodiques par site

Dans la page de vérification des dates d’expiration des abonnements de périodique, une limitation par site est possible si l’utilisateur est super- bibliothécaire ou à la permission super-périodique. Pour les autres utilisateurs, seuls les abonnements de son site de rattachement sont affichés.

Réclamation de périodiques par site

Les périodiques qui peuvent être réclamés par utilisateur doivent appartenir au site de l’utilisateur, sauf si l’utilisateur est super-bibliothécaire ou s’il a la permission super-périodique.

Persistance du texte dans la barre d’accès rapide de l’interface pro

Dans l’interface professionnelle, en haut de chaque page, il y a une barre d’accès rapide aux principales fonctions de Koha. C’est une boîte de texte, sous laquelle quatre onglets permettent de choisir la fonction que l’on souhaite atteindre : Prêter, Retourner, Recherche adhérent et Dans le catalogue. Jusqu’à présent, le texte qui était entré dans la zone de saisie était perdu quand on passait d’un onglet à l’autre. Le texte est désormais persistant d’un onglet à l’autre.

Extension de la préférence CalendarFirstDayOfWeek

La préférence système CalendarFirstDayOfWeek permet de définir quel est le premier jour de la semaine affiché dans les calendriers de Koha. Deux valeurs étaient possibles jusqu’à présent : samedi ou dimanche. Désormais tout jour de la semaine peut être choisi.

Editeur HTML pour les préférences systèmes

Certaines préférence système peuvent être modifiées avec un éditeur HTML. Activez cette fonctionnalité avec la préférence système WYSIWYGinSystemPreferences.

Nouveau jeu d’icônes

Le jeu d’icônes «Glyphicons» a été remplacé par «Font Awesome». Les nouvelles icônes présentes l’avantage d’avoir une meilleure licence d’utilisation et d’être plus «jolies».

Affichage zone MARC21 773

La feuille XSL MARC21 a été modifiée pour afficher la zone 773 quand l’indicateur 1 est différent de 1.

Script d’export utilisable avec/sans interface web

Le script d’export a été modifié pour être utilisable, dans une même version, à la fois dans l’interface web de Koha et en ligne de commande.

Amélioration du serveur OAI-PMH

Le serveur OAI-PMH de Koha a été amélioré : (a) support des notices supprimées (mode «transient») ; (b) support de l’heure dans les paramètres de moissonnage par intervalle de dates ; (c) inclusion des informations de niveau exemplaire.

Amélioration du code

Suppression de la table reserveconstraints

La table reserveconstraints n’est plus utilisée dans Koha depuis plusieurs versions. Elle est supprimée en montée de version et toute référence à cette table dans le code Koha a été supprimée.

Suppression de «l’ethnicité»

La notion d’éthnicité des adhérents a été entièrement supprimée de Koha.

Rationalisation de la gestion des valeurs autorisées

La gestion des valeurs autorisées, en interne dans Koha, a été entièrement revue et rationalisée. Le code a été regroupé dans des modules, évitant ainsi au reste du code de Koha d’accéder directement à la base de données pour accéder aux valeurs autorisées. Ce travail est ce qui a permis de rendre traduisibles les valeurs autorisées.

Factorisation de la purge de l’historique de recherche

L’historique de recherche était réalisé de façon similaire dans deux portions distinctes du code de Koha. Ces deux portions ont été fusionnées.

Dépréciation du module C4::Dates

Un nouveau module Koha::DateUtils remplace le module historique C4::Dates. L’ancien module était utilisé partout dans le code de Koha. Un travail très important de reprise du code a été nécessaire pour remplacer partout les appels au module déprécié.

Suppression du code «mort»

De nombreuses portions du code de Koha correspondent à des fonctionnalités qui ont disparues ou qui ne sont plus utilisées. Ces portions de codes ont été nettoyées.

Abstraction du type des notices

Un mécanisme d’abstraction du type des notices a été introduit dans Koha. L’abstraction des notices est un préalable à la prise en charge dans une Catalogue Koha de types de données autres que MARC21 ou Unimarc. C’est une ouverture vers le web sémantique.

Amélioration des performances en circulation

L’utilisation du système de cache de Koha a permis d’améliorer sensiblement les performances du système dans le module de Circulation.

Article précédent Article suivant