I was yesterday in OUEST-PROVENCE (called OP in this mail) to work with
them on their version of Koha.
We all agree on the following position : developp as many features as
possible to be in official CVS. Even if it means developping a little
bit more parameters tables, to have a behaviour that anyone can use.
They worked on borrowers management, here is what they have done and
will do in the next 2 weeks :
* in koha 2.x we had 3 kinds of borrowers : Adults, Institutions,
Childrens. Those 3 kinds of borrowers where hardcoded (A, I, C), and not
fully functionnal. OP has defined a new row in categories table :
"cateogy_type". a category_type can be <A>dult, <C>hildren,
<I>nstitution, <P>rofessional. The library can thus define in the
database which catagories are what (and we can have more than 1 category
for <C> for example : Baby, boy, girl,...)
* when a library want to add a borrower, it 1st must select what kind of
borrower it want to add (A,I,C,P). Then the "member add" begins. Every
category_type has it's own template. Add is divided in 3 parts :
PART 1 : general information : name, surname (where applicable),
category (baby, boy, girl in my previous sample, if you choose
category_type='C'), and *city*
The city refers to a new table with city/zipcode. The library can fill
or ignore this table. If empty, the list does not appear. Otherwise, the
list appear. Useful to put usefull a list of common cities your library has.
PART 2 : addresses (personnal, professionnal, parent's one...),
including mail, fax, ... In the previous part, if a city has been
choosen, zip and city name are automatically filled and can be modified
The address has been modified to be separated in 3 parts : number, kind
of road (avenue, road, place...), road name. The list of "road type" is
defined in a separate table. If empty, once again, it does not appear.
Separating address in 3 parts will be a useful thing to have Geographic
information on borrowers. OP plans to connect Koha to a Geographic
Information Système (SIG in french) on the long term.
PART 3 : library use (opac note...)
nothing new or important here, if I don't mind.
On every PART value checking is done on client side (new behaviour, in
improved later is that the list of mandatory fields can be defined in a
systempreference (zipcode is mandatory in France, for example, it's not
is some countries)
Last note : OP will also reorganize the borrowers table to normalize
For instance, there are many addresses/zipcode..., each having it's own
"nick". I suggested to adopt the following rules : each
address/mail/phone/fax information begins with a A or a B, the A being
"the most important one", the B being the alternative one.
For example : Aaddress1, Aaddress2, Azipcode, Acity...
Last note (2) : adding childrens : I suggested to add 3 ways to add a
- from the parent, add a children = in this case, the guarantorcode is
kept, and the B adress is automatically set to the parent one.
- create a children from home page, and in PART 2, add a ... button to
find the parent to set guarantorcode (and B address)
- create a children that has no parent in the database (no
guarantorcode, and thus no B address automatically set).
This last behaviour being usefull for OP, as childs can subscribe to the
library without their parents being members.
Expected timeline : code working in around 3 weeks (next week being
holidays for OP developpers), but on default templates. We agree to let
me install a copy on bureau.paulpoulain.com to let you see how it works,
and commit code if everybody agrees.
Let me know your opinion on this. Joshua, I let you update release notes
Paul POULAIN et Henri Damien LAURENT
en logiciels libres et bibliothéconomie (http://www.koha-fr.org)