From pascale.nalon at mines-paristech.fr  Mon Nov 22 09:24:30 2010
From: pascale.nalon at mines-paristech.fr (Pascale Nalon)
Date: Mon, 22 Nov 2010 09:24:30 +0100
Subject: [koha-Infos] Fwd: conference de la fulbi
References: <18950F6CDF0AD0458B64A56E137231A23C69267954@MS1101M1>
Message-ID: <69DBBC27-9BD2-4CCA-8E82-9B0D760BCD50@mines-paristech.fr>

Bonjour,

KohaLa étant adhérent à la FULBI je vous communique le programme de la journée d'étude.

Cordialement
Pascale Nalon
Présidente KohaLa
Bibliothèque de Mines ParisTech
35, rue St Honoré
77305 Fontainebleau Cedex
pascale.nalon at mines-paristech.fr
01 64 69 48 79


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

> De : <robert.zachayus at banque-france.fr>
> Date : 18 novembre 2010 16:37:17 HNEC
> À : <b.thibault at mairie-poitiers.fr>, <elisabeth.derderian at mairie-villeurbanne.fr>, <marie-germaine.jullien at biu-toulouse.fr>, <s.sauge at dole.org>, <francoise.boissiere at bib.ens-cachan.fr>, <claudine.even at sciences-po.fr>, <FZANIER at agirc-arrco.fr>, <maryline.larret at ville-montivilliers.fr>, <veronique.deltour at cg13.fr>, <agaudion at mairie-chassieu.fr>, <pascale.nalon at mines-paristech.fr>, <philippe.pineau9 at wanadoo.fr>, <maximilien.savoye at univ-metz.fr>
> Cc : <claire.scopsi at cnam.fr>
> Objet : conference de la fulbi
> 
> Bonjour
> Je vous adresse le programme de la prochaine conférence de la FULBI qui aura lieu le 20 janvier 2011 (en 2001 la FULBI aura 20ans)
> Merci de la communiquer très rapidement à vos adhérents pour qu?ils s?inscrivent :

http://www.fulbi.fr/spip.php?article38

> Très cordialement
> Robert ZACHAYUS
> Président de la FULBI
>  
> **************************************************************
> Ce mel est a l'attention exclusive des destinataires designes.
> Il peut contenir des informations confidentielles.
> Si vous le recevez par erreur, merci d'en informer sans delai l'expediteur.
> 
> Le contenu de ce mel ne pourrait engager la responsabilite de la Banque de France
> que s'il a ete emis par une personne dument habilitee agissant dans le strict
> cadre des fonctions auxquelles elle est employee et a des fins non etrangeres a ses attributions.
> ************************************************************** 







-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: </pipermail/infos/attachments/20101122/13005f5f/attachment.htm>

From rachid.aliouat at univ-lille3.fr  Mon Nov 22 14:04:18 2010
From: rachid.aliouat at univ-lille3.fr (Rachid Aliouat)
Date: Mon, 22 Nov 2010 14:04:18 +0100
Subject: [koha-Infos] =?iso-8859-1?q?Les_p=E9riodiques_dans_Koha?=
In-Reply-To: <4CE67418.9090102@univ-lille3.fr>
References: <4CE64AD3.3090900@univ-lille3.fr>	<EBAF187946A337449E7577D1CE217F41338AAA6EAB@EXCH-CLUSTER.ad.univ-lyon3.fr>	<4CE65EBA.2070403@univ-lille3.fr>
	<4CE67418.9090102@univ-lille3.fr>
Message-ID: <4CEA6A52.5040907@univ-lille3.fr>

 >j'ai remonté ce bug dans le bugzilla de Koha-community.
 >http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5420

Celui là  n'est pas un bug. je l'ai enlevé sur le site koha-community. 
Le premier perio avait été créé manuellement et donc il avait bien le 
942$s à 1. Les autres ont été importé sans l'information 942$s.
---------------------

j'ai aussi remonté un autre bug au sujet de la périodicité de type 
"saisonniere" qui génére une saison "nothing" avant "winter".
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5319

Le 19/11/2010 13:56, Rachid Aliouat a écrit :
>
> Dans le paramétrage de la grille de catalogage, il faut que le
> sous-champs "s" du 942 ne soit pas caché(-5). Mettre 0. (voir afficher
> plus de restriction)
>
> Le 19/11/2010 12:25, Nadège Sieckelinck a écrit :
>> Bonjour,
>> je viens de vérifier, effectivement pour le titre dont l'abonnement
>> apparait dans l'Opac, il a un sous champ s avec la valeur 1 dans la zone
>> 942, alors que les autres n'ont pas ce sous-champ.
>> Comment faire pour l'ajouter ?
>>
>> Je vous remercie.
>> Nadège Sieckelinck
>>
>> BERNON Jean a écrit :
>>> Avez-vous vérifié que la zone biblio.serial des notices qui ont ce
>>> problème est bien à 1 ? Il arrive que cette zone soit mal encodée et
>>> génère le dysfonctionnement que vous signalez.
>>> -----Message d'origine-----
>>> De : infos-bounces at listes.koha-fr.org
>>> [mailto:infos-bounces at listes.koha-fr.org] De la part de Nadège
>>> Sieckelinck
>>> Envoyé : vendredi 19 novembre 2010 11:01
>>> À : infos at listes.koha-fr.org
>>> Objet : [koha-Infos] Les périodiques dans Koha
>>>
>>> Bonjour,
>>>
>>> Nous testons koha version 3.2
>>> Nous rencontrons des problèmes avec les périodiques : modèle
>>> d'abonnement et prévisionnel.
>>> Sur quelques abonnements créés, il n'y a que pour un titre pour lequel
>>> nous avons l'onglet abonnement dans l'Opac.
>>> Nous avons beau comparer les modèles d'abonnement nous ne voyons pas
>>> d'où vient le problème.
>>> Quelqu'un aurait-il rencontré se problème ?
>>>
>>> Merci pour votre aide,
>>> cordialement
>>>
>>
>
>


-- 
Rachid Aliouat
informaticien
Service Commun de la Documentation
Université de LILLE 3
Domaine du Pont de bois
59650 Villeneuve d'Ascq
tel:032041 7054
mel:rachid.aliouat at univ-lille3.fr
http://www.univ-lille3.fr

From bibli.alliance at francedc.org  Mon Nov 22 23:08:18 2010
From: bibli.alliance at francedc.org (Bibli Alliance AFW)
Date: Mon, 22 Nov 2010 17:08:18 -0500
Subject: [koha-Infos] Migration BCDI vers Koha ?
Message-ID: <4ceaead2.896ae50a.5549.fffffadf@mx.google.com>

Bonjour à tous, 

 

Je suis bibliothécaire à l'Alliance Française de Washington DC. Nous allons
acquérir un nouveau SIGB et abandonner l'actuel, BCDI (notre version date de
2006, "spécial Réseau. Client. V.1.70 du 28-12-2006"). Koha est une
possibilité. 

 

Y a t-il des collègues parmi vous qui ont migré de BCDI à Koha ? Le
transfert s'est il effectué sans accrocs ? Aviez-vous des compétences
informatiques particulières ? Avez-vous été épaulé par la communauté Koha ? 

 

Merci !

 Nadia  

 

Nadia Pazolis-Gabriel

Librarian / Bibliothécaire @ Alliance Française de Washington

2142 Wyoming Avenue, NW

Washington, DC 20008

Tel:  202-234-7911 ext. 14 

 

Monday-Tuesday 12noon - 8pm; Wednesday-Thursday 10am - 6pm; Friday 10am -
5pm; Saturday 11am - 4pm

 

Please consider donating books to your library! See our
<http://www.francedc.org/en/Article.aspx?id=553> Wish Lists page for
details. 

 

To subscribe to our email lists and receive our messages on French classes,
cultural activities and library aquisitions, please go to  www.francedc.org
then "sign up for our e-newsletter". 

 

The Alliance Française de Washington tiered membership program: exclusive
benefits at partner organizations! Become a member today at
<http://www.francedc.org/> www.francedc.org.  

 

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: </pipermail/infos/attachments/20101122/245bfcbb/attachment.htm>

From d.girod at ipnl.in2p3.fr  Tue Nov 23 09:56:16 2010
From: d.girod at ipnl.in2p3.fr (Dominique Girod-Chanzy)
Date: Tue, 23 Nov 2010 09:56:16 +0100
Subject: [koha-Infos] table sessions schema koha
Message-ID: <4CEB81B0.9030701@ipnl.in2p3.fr>

Bonjour,

y a t-il un autre moyen de vider la table des sessions de la base koha 
différent de celui de programmer un script qui la vide régulièrement ?
Merci

-- 
Dominique Girod
Documentation IN2P3&  IPNL
4 rue Enrico Fermi
69622 VILLEURBANNE Cedex
04 72 43 16 77




From fridolyn.somers at progilone.fr  Tue Nov 23 13:35:53 2010
From: fridolyn.somers at progilone.fr (Fridolyn SOMERS)
Date: Tue, 23 Nov 2010 13:35:53 +0100
Subject: [koha-Infos] table sessions schema koha
In-Reply-To: <4CEB81B0.9030701@ipnl.in2p3.fr>
References: <4CEB81B0.9030701@ipnl.in2p3.fr>
Message-ID: <4CEBB529.2090705@progilone.fr>

Bonjour,

C'est à mon avis possible directement dans le serveur de base de données 
à l'aide d'un "trigger" : 
http://dev.mysql.com/doc/refman/5.0/fr/using-triggers.html
Cela permet de paramétrer une action (vider les sessions les plus 
anciennes) lors de l'insertion d'une nouvelle entrée dans la table (des 
sessions).

Le top serait de combiner avec une procédure stockée mais ce n'est pas 
possible actuellement dans MySQL.


Reste que c'est pas plus facile que de programmer un script ou un cronjob.

Cordialement,

On 23/11/2010 09:56, Dominique Girod-Chanzy wrote:
> Bonjour,
>
> y a t-il un autre moyen de vider la table des sessions de la base koha 
> différent de celui de programmer un script qui la vide régulièrement ?
> Merci
>


-- 
Fridolyn SOMERS
/*Société PROGILONE*
24b, rue Jean Baldassini
69007 LYON
+33(0)4.72.76.29.22
/ fridolyn.somers at progilone.fr <mailto:fridolyn.somers at progilone.fr>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: </pipermail/infos/attachments/20101123/82e486c5/attachment.htm>

From henridamien.laurent at biblibre.com  Tue Nov 23 14:03:02 2010
From: henridamien.laurent at biblibre.com (LAURENT Henri-Damien)
Date: Tue, 23 Nov 2010 14:03:02 +0100
Subject: [koha-Infos] table sessions schema koha
In-Reply-To: <4CEBB529.2090705@progilone.fr>
References: <4CEB81B0.9030701@ipnl.in2p3.fr> <4CEBB529.2090705@progilone.fr>
Message-ID: <4CEBBB86.9000300@biblibre.com>

Le 23/11/2010 13:35, Fridolyn SOMERS a écrit :
>  Bonjour,
> 
> C'est à mon avis possible directement dans le serveur de base de données
> à l'aide d'un "trigger" :
> http://dev.mysql.com/doc/refman/5.0/fr/using-triggers.html
> Cela permet de paramétrer une action (vider les sessions les plus
> anciennes) lors de l'insertion d'une nouvelle entrée dans la table (des
> sessions).
> 
> Le top serait de combiner avec une procédure stockée mais ce n'est pas
> possible actuellement dans MySQL.
> 
> 
> Reste que c'est pas plus facile que de programmer un script ou un cronjob.
> 
> Cordialement,

Personnellement, je ne trouve pas qu'un
mysql -u user -h host -ppassword -e 'TRUNCATE sessions'
Soit si compliqué que cela.
Par ailleurs, si vous souhaitez un script, il existe et s'appelle
cleanup_database.pl dans misc/cronjobs.
cf. :
http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=misc/cronjobs/cleanup_database.pl;h=133311178993021f33b3c800473f4127ac9eb34c;hb=HEAD

Il suffit d'ajouter les bons paramètres.
Cordialement.
-- 
Henri-Damien LAURENT
BibLibre

From fridolyn.somers at progilone.fr  Tue Nov 23 14:30:29 2010
From: fridolyn.somers at progilone.fr (Fridolyn SOMERS)
Date: Tue, 23 Nov 2010 14:30:29 +0100
Subject: [koha-Infos] table sessions schema koha
In-Reply-To: <4CEBBB86.9000300@biblibre.com>
References: <4CEB81B0.9030701@ipnl.in2p3.fr> <4CEBB529.2090705@progilone.fr>
	<4CEBBB86.9000300@biblibre.com>
Message-ID: <4CEBC1F5.2020305@progilone.fr>

On 23/11/2010 14:03, LAURENT Henri-Damien wrote:
> Le 23/11/2010 13:35, Fridolyn SOMERS a écrit :
>>   Bonjour,
>>
>> C'est à mon avis possible directement dans le serveur de base de données
>> à l'aide d'un "trigger" :
>> http://dev.mysql.com/doc/refman/5.0/fr/using-triggers.html
>> Cela permet de paramétrer une action (vider les sessions les plus
>> anciennes) lors de l'insertion d'une nouvelle entrée dans la table (des
>> sessions).
>>
>> Le top serait de combiner avec une procédure stockée mais ce n'est pas
>> possible actuellement dans MySQL.
>>
>>
>> Reste que c'est pas plus facile que de programmer un script ou un cronjob.
>>
>> Cordialement,
> Personnellement, je ne trouve pas qu'un
> mysql -u user -h host -ppassword -e 'TRUNCATE sessions'
> Soit si compliqué que cela.
> Par ailleurs, si vous souhaitez un script, il existe et s'appelle
> cleanup_database.pl dans misc/cronjobs.
> cf. :
> http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=misc/cronjobs/cleanup_database.pl;h=133311178993021f33b3c800473f4127ac9eb34c;hb=HEAD
>
> Il suffit d'ajouter les bons paramètres.
> Cordialement.
Effectivement, le script /clean_database.pl/ est la meilleure solution.

Comme l'indique la doc :

Usage: $0 [-h|--help] [--sessions] [--sessdays DAYS] [-v|--verbose] [--zebraqueue DAYS]
         [-m|--mail]
    -h --help          prints this help message, and exits, ignoring all
                       other options
    
--sessions         purge the sessions table.  If you use this while users
                       are logged into Koha, they will have to reconnect.
    
--sessdays DAYS    purge only sessions older than DAYS days (use together with sessions parameter).
    
-v --verbose       will cause the script to give you a bit more information
                       about the run.
    --zebraqueue DAYS  purge completed entries from the zebraqueue from
                       more than DAYS days ago.
    -m --mail          purge the mail queue.

Purger toute la table des sessions :
/clean_database.pl --sessions
/
Purger les sessions anciennes de plus de 15 jours (par exemple) : /
     clean_database.pl --sessions ----sessdays 15

/Pour ce qui est de son automatisation via /cron/, voir le fichier 
d'exemple /misc/cronjobs/crontab.example.
//
Cdt,
/
-- 
Fridolyn SOMERS
/*Société PROGILONE*
24b, rue Jean Baldassini
69007 LYON
+33(0)4.72.76.29.22
/ fridolyn.somers at progilone.fr <mailto:fridolyn.somers at progilone.fr>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: </pipermail/infos/attachments/20101123/8d601f68/attachment.htm>

From marc.chantreux at biblibre.com  Tue Nov 23 14:37:02 2010
From: marc.chantreux at biblibre.com (Marc Chantreux)
Date: Tue, 23 Nov 2010 14:37:02 +0100
Subject: [koha-Infos] table sessions schema koha
In-Reply-To: <4CEBBB86.9000300@biblibre.com>
References: <4CEB81B0.9030701@ipnl.in2p3.fr> <4CEBB529.2090705@progilone.fr>
	<4CEBBB86.9000300@biblibre.com>
Message-ID: <20101123133702.GB14732@auckland.lan>

On Tue, Nov 23, 2010 at 02:03:02PM +0100, LAURENT Henri-Damien wrote:
> Le 23/11/2010 13:35, Fridolyn SOMERS a écrit :
> >  Bonjour,
> > 
> > C'est à mon avis possible directement dans le serveur de base de données
> > à l'aide d'un "trigger" :
> > http://dev.mysql.com/doc/refman/5.0/fr/using-triggers.html
> > Cela permet de paramétrer une action (vider les sessions les plus
> > anciennes) lors de l'insertion d'une nouvelle entrée dans la table (des
> > sessions).

Et amoindrir nos chances de passer à Postgresql un jour? Je
n'ai pas de chiffres pour vérifier mais mon role a biblibre fait de moi
un des plus gros administrateurs koha de france (en terme de nombre
d'installs) et mon ancien boulot m'a permis d'utiliser et administrer
des applis Postgresql. les deux experiences me permettent de mesurer
tout ce que koha perd a rester dépendant de mysql. J'aimerais vraiment
que ca cesse ...

> > Reste que c'est pas plus facile que de programmer un script ou un cronjob.

le comportement par defaut de koha (utilisation de la table sessions)
n'est pas en adequation avec l'immense majorité des installs: koha peut
utiliser /tmp et cela devrait etre le comportement par defaut. Si vous
etes sur un serveur: vous avez certainement un tmpreaper de configuré et
et vous n'avez meme pas besoin de configurer quoi que ce soit! 

> Personnellement, je ne trouve pas qu'un
> mysql -u user -h host -ppassword -e 'TRUNCATE sessions'
> Soit si compliqué que cela.

configurer ~/.my.cnf
a) evite d'avoir un mdp dans le script ou la console 
b) simplifie la lecture

cordialement 
-- 
Marc Chantreux
BibLibre, expert en logiciels libres pour l'info-doc
http://biblibre.com

From paul.poulain at biblibre.com  Tue Nov 23 14:51:38 2010
From: paul.poulain at biblibre.com (Paul Poulain)
Date: Tue, 23 Nov 2010 14:51:38 +0100
Subject: [koha-Infos] table sessions schema koha
In-Reply-To: <20101123133702.GB14732@auckland.lan>
References: <4CEB81B0.9030701@ipnl.in2p3.fr>
	<4CEBB529.2090705@progilone.fr>	<4CEBBB86.9000300@biblibre.com>
	<20101123133702.GB14732@auckland.lan>
Message-ID: <4CEBC6EA.5010008@biblibre.com>

Le 23/11/2010 14:37, Marc Chantreux a écrit :
> On Tue, Nov 23, 2010 at 02:03:02PM +0100, LAURENT Henri-Damien wrote:
>> Le 23/11/2010 13:35, Fridolyn SOMERS a écrit :
>>>  Bonjour,
>>>
>>> C'est à mon avis possible directement dans le serveur de base de données
>>> à l'aide d'un "trigger" :
>>> http://dev.mysql.com/doc/refman/5.0/fr/using-triggers.html
>>> Cela permet de paramétrer une action (vider les sessions les plus
>>> anciennes) lors de l'insertion d'une nouvelle entrée dans la table (des
>>> sessions).
> Et amoindrir nos chances de passer à Postgresql un jour? Je
> n'ai pas de chiffres pour vérifier mais mon role a biblibre fait de moi
> un des plus gros administrateurs koha de france (en terme de nombre
> d'installs) et mon ancien boulot m'a permis d'utiliser et administrer
> des applis Postgresql. les deux experiences me permettent de mesurer
> tout ce que koha perd a rester dépendant de mysql. J'aimerais vraiment
> que ca cesse ...
Pour compléter ce que dit Marc : l'un des objectifs de Chris Cormack, le
Release Manager pour la 3.4 est de réduire la dépendance à mySQL pour
pouvoir devenir agnostique vis à vis de la BD. Ce ne sera pas atteint
pour la 3.4, mais :
* ce qui existe déjà va commencer à être nettoyé
* ce qui est nouveau devra être DB-agnostique et par corrélation toute
nouveauté spécifique mySQL sera refusée.

Pour ceux qui ne s'intéressent que de loin à l'éco-système du libre,
mySQL a été racheté par Sun l'an passé. Sun a été racheté par Oracle
cette année. Du coup, c'est Oracle qui "possède" mySQL. Les gens qui ont
un contrat de support avec mySQL-AB ont déjà vu leur contrat ... doubler
en prix dans certains cas.
De plus, Oracle est vraiment pas un "bon gars" au niveau logiciels
libres. Du coup, des fourches sont en cours :
* OpenOffice => LibreOffice
* mySQL => MariaDB
* Java, ca chauffe aussi (avec la fondation Apache qui menace de claquer
la porte des instances décisionnaires de Java)

Bref, tout le monde commence à se dire qu'il est grand temps de prendre
notre indépendance par rapport à mySQL (en plus des avantages techniques
objectifs que cela aura)

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08


From Jean-Manuel.Broust at univ-lyon2.fr  Thu Nov 25 21:22:19 2010
From: Jean-Manuel.Broust at univ-lyon2.fr (Jean-Manuel BROUST)
Date: Thu, 25 Nov 2010 21:22:19 +0100 (CET)
Subject: [koha-Infos] champs obligatoires dans la grille d'acquisition
Message-ID: <2289439.431.1290716541112.JavaMail.root@co7>

bonjour,

Sur la version 3.2, je bloque depuis un moment sur ce problème :
J'ai créé une grille ACQ pour que le champ d'exemplaire soit utilisé à la commande. (création des exemplaires à la commande).
Dans cette grille, j'ai rendu certains sous champs des exemplaires obligatoires mais aucun contrôle ne semble s'effectuer : je peux valider ma commande sans que ces sous champs d'exemplaires déclarés obligatoires ne soient saisis.

Est ce un bug ou un fonctionnement "normal" du module acquisitions de koha avec la grille ACQ ?

Merci de votre aide,:-)


Jean-Manuel Broust
Service commun de documentation - Lyon 2
jean-manuel.broust at univ-lyon2.fr
04 78 69 77 47 
04 78 77 31 69 


From frederic at tamil.fr  Fri Nov 26 07:44:48 2010
From: frederic at tamil.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Demians?=)
Date: Fri, 26 Nov 2010 07:44:48 +0100
Subject: [koha-Infos] champs obligatoires dans la grille d'acquisition
In-Reply-To: <2289439.431.1290716541112.JavaMail.root@co7>
References: <2289439.431.1290716541112.JavaMail.root@co7>
Message-ID: <4CEF5760.6010405@tamil.fr>


> Sur la version 3.2, je bloque depuis un moment sur ce problème :
> J'ai créé une grille ACQ pour que le champ d'exemplaire soit utilisé à 
> la commande. (création des exemplaires à la commande).
> Dans cette grille, j'ai rendu certains sous champs des exemplaires 
> obligatoires mais aucun contrôle ne semble s'effectuer : je peux 
> valider ma commande sans que ces sous champs d'exemplaires déclarés 
> obligatoires ne soient saisis.
> Est ce un bug ou un fonctionnement "normal" du module acquisitions de 
> koha avec la grille ACQ ?

Je peux reproduire ce qui, selon moi, est un dysfonctionnement. Je viens 
de signaler comme bug ce que vous décrivez :

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5446

Merci.
--
Frédéric DEMIANS