[koha-Infos] Fwd: traduction

Jeu 28 Juil 11:37:50 CEST 2005

Bonjour,

Ci-dessous  et en français le message de Paul sur les nouvelles 
fonctionnalités :

Début du message réexpédié :

> Bonjour,
>
> Voici une liste des fonctionnalités qu'Henri Damien et moi-même allons 
> bientôt coder (rappel pour ceux qui n’ont pas suivi : Henri Damien et 
> moi-même travaillons ensemble).
>
> Elles seront toutes dans la prochaine version majeure, certaines 
> d’entre elles seront portées dans la branche 2.2.x (ce qui sera 
> spécifié dans ce mail. Quand c’est écrit « bientôt portée », cela 
> signifie que le rapatriement sera fait dès que possible, parce que ça 
> été demandé par un de mes clients. Sinon, ce sera porté quand 
> hdl/moi-même aurons le temps et si c’est demandé par quelqu’un.)
>
>
> * 1- Gestion multi-site améliorée *
>
> Quelques-uns de mes clients ont plus d’une site pour la circulation, 
> les emprunteurs, ET pour les acquisitions, catalogage…
> Dans Koha 2.2.x, tous les bibliothécaires ont accès à tout dans le 
> module (s’ils ont le bon loggin).
> Quelques bibliothèques ont besoin d’avoir « budget X est pour la site 
> AA », et « budget Y est pour la site BB » ou « le doit être géré 
> seulement par la bibliothèque qui le possède ».
>
> Nous allons donc ajouter les fonctionnalités suivantes :
>
>
> 1 - A BUDGET (BOOKFUND)
>
> Une nouvelle ligne sera ajoutée au budget, appelée « Code de Site ». 
> Si le code est
> « », alors tout le monde peut faire des acquisitions sur ce budget. Si 
> le code est « XX », alors seul un bibliothécaire du site « XX » pourra 
> faire des acquisitions sur ce budget.
> Cela va changer :
> - le paramètre >> bookfund admin screen (qui s'ajoute à la liste)
> - le script acqui-home.pl : montrant seulement les budgets que 
> l’utilisateur peut utiliser lorsqu’il émet une commande.
> - dans nouvelle notice , le bibliothécaire peut choisir le budget dans 
> une liste restreinte.
>
> On a seulement besoin d’une nouvelle colonne dans la table aqbookfund. 
> Ce sera bientôt dans la branche majeure et porté dans la 2.2.x
>
>
> 1 – B SITE DISTINCT
>
> Dans certaines bibliothèques multi-site (comme NPL) la distinction des 
> sites concerne seulement les modules lecteurs/circulation. Toutes les 
> acquisitions et le catalogage sont faits dans un site unique .
> Dans d’autres bibliothèques multi-site, chaque site a sa propre équipe 
> de catalogage, d’acquisition… Ainsi, nous avons besoin d’une solution 
> pour ces bibliothèques. Je propose d’avoir une nouvelle entrée « 
> préférencesystème », appelée « IndependantBranches »,.
> Quand ce n’est pas activé, le fonctionnement est comme dans 2.2.x
> Quand c’est activé, le fonctionnement devient :
> * dans le module acquisition, seules les suggestions faite par un 
> utilisateur du même site que le bibliothécaire peuvent être 
> acceptées/rejetées.
> * dans le module acquisition, une commande peut être 
> modifiée/reçue/fermée seulement par un bibliothécaire venant du même 
> site que celui qui a créé le panier.
> * dans le module catalogue, une notice peut être 
> modifiée/effacée/créée seulement par un bibliothécaire du site 
> propriétaire du document.
> * dans le module lecteur, un lecteur peut être crée/modifié seulement 
> par un bibliothécaire du même site que le lecteur .
>
> Pas besoin de changement dans la Base de Données , ce sera bientôt 
> dans la version majeure et porté dans la branche 2.2.
>
>
> * 2 – Autres améliorations *
>
> 2 – C Tracer qui fait quoi
> Koha va enregistrer quel bibliothécaire crée/modifie une notice, et 
> quand (mais la question se pose pour ce qu’ il modifie ?, car 
> enregistrer les modifications peut être très complexe)
> Ça nécessite d’une nouvelle table dans la Base de Données, ce serait 
> seulement dans la version majeure.
>
> 2 – D Commandes en retard
> Dans les acquisitions, créer une nouvelle page pour voir, pour un 
> libraire donné les lignes de commande qui ne sont toujours pas reçues 
> (+ impression de cette liste « Réceptions en retard »). La page sera 
> comme bull/lateissues.pl où vous pouvez choisir un fournisseur et voir 
> quels sont ses dernières livraisons. La liste montrera les 
> informations de la commande, incluant panier #, date de commande…)
> Pas de Changement de la Base de Données ce sera dans la version 
> majeure porté dès que possible dans la branche 2.2.
>
> 2 – E Note sur les périodiques
> Gestion des périodiques : ajouter une colonne à la table périodique, 
> pour les notes du bibliothécaire (comme « appel au libraire le 06 mai, 
> arriverait dans 10 jours ») on a besoin d’une nouvelle colonne dans la 
> Base de données. Ce sera dans la version majeure, porté dans la 2.2.x
>
> 2 – F Traceur de l’historique du libraire
> Un outil pour suivre l'historique des relances (pour les acquisitions 
> et les périodiques).
> Quand vous réclamerez un livre ou périodique en retard au fournisseur, 
> la réclamation sera stockée dans une table historique. Ce sera dans la 
> version majeure, pas encore complètement analysé, libre à vous de 
> suggérer comment le faire et que faire exactement.
>
> 2 – G Contact mail
> Ajouter un « contact mail » dans les tables sites. Ce mail sera 
> affiché dans divers endroits (dans l’OPAC par exemple) et utilisé pour 
> des tâches périodiques. On a besoin d’une colonne dans la table « 
> branches ». Ce sera dans la version majeure, porté dans la 2.2.
>
> 2 – H « Liste de circulation»
> Dans les périodiques (création d’abonnement), le bibliothécaire pourra 
> sélectionner des utilisateurs recevant les numeros d’un périodique à 
> tour de rôle.
> Cette liste sera imprimée par le bibliothécaire quand il recevra un 
> fascicule. ( y fixer alors la liste , et le faire circuler entre les 
> utilisateurs. La «liste des destinataires» peut être ordonnée par le 
> bibliothécaire.
> Dans l’OPAC, les utilisateurs peuvent s’abonner et se désabonner à 
> n’importe quelle « liste de circulation d’un abonnement ». Une 
> préférence système (CirculationList) activera ou inactivera cette 
> fonction (s'abonner/désabonner à l'OPAC). Ce sera dans la version 
> majeure.
>
> 2 – I «Alerte de parution d'un périodique
> Avec cette fonctionnalité, pour les périodiques, un utilisateur peut 
> s’abonner à l’ « l’alerte de parution ». Pour tous les volumes 
> déclarés arrivés/manquant, un mail est envoyé à tous les abonnés de 
> cette liste. Le mail prévient l’utilisateur que le volume est arrivé 
> ou manquant. Ce sera dans la version majeure.
>
> 2 – J Calcul de la date de retour
> Pour l’instant, la date de retour ne tient pas compte de l'échéance de 
> l'inscription de l’emprunteur. Une Préférence système sera ajoutée 
> dans Koha, pour modifier le schéma de calcul de la date de retour :
> * ReturnBeforeExpiry = oui  la date de retour ne peut pas être après 
> la date d’expiration
> * ReturnBeforeExpiry = non  la date de retour peut être après la date 
> d’expiration
> Ce sera dans la version majeure et bientôt porté dans la 2.2.x.
>
> -- 
> Paul POULAIN
> Consultant indépendant en logiciels libres
> responsable francophone de koha (SIGB libre http://www.koha-fr.org)
>
>
-- 
Pascale Nalon
Bibliothèque de l'Ecole des Mines de Paris
35, rue St Honoré
77300 Fontainebleau
Tel : 01 64 69 48 79

-------------- section suivante --------------
Une pièce jointe non texte a été nettoyée...
Nom: non disponible
Type: text/enriched
Taille: 7363 octets
Desc: non disponible
Url: http://ob.paulpoulain.com/pipermail/infos/attachments/20050728/c1bd11ce/attachment-0001.bin