[Koha-devel] feature list for Koha 2.4/3.0 (hdl & paul coding planning)

[Paul POULAIN]

Hi,

Here is a list of features that hdl & me will code soon (reminder for 
thos who didn't follow : hdl & me are working together)

All of them will be in next major version, some of them being backported 
to 2.2.x (that will be specified in this mail. when it's written 
"backported soon", it means that the backport will be done asap, as it's 
requested by one of my customers. otherwise, will be backported when 
hdl/me has time & if requested by someone)

*1- Improved multi-branch support*
===============================
Some of my libraries have more than one branch for circulation, 
borrowers, AND for acquisition, cataloguing...
In Koha 2.2.x, all librarian have access to everything in a module (if 
they have the correct login).
Some libraries need to have "budget X is for the branch AA", and "budget 
Y is for the branch BB" or "item must be created/modified only by the 
library that own them".

So we will add the following features :

1-A BUDGET (BOOKFUND)
----------
A new row will be added to the budget, called "branchcode". If 
branchcode is '', then everybody can acquire using this budget.
If branchcode is 'XX', then only a librarian from branch 'XX' can 
acquire using this budget.
This will change :
- the parameter >> bookfunds admin screen (adding the list)
- the acqui-home.pl script : showing only bookfunds the user can use 
when placing an order.
- in newbiblio, the librarian can choose the bookfund from the limited list.

needs only a new row in aqbookfund table. will be in head & backported 
soon in 2.2.x

1-B SEPARATE BRANCH
--------------
in some multi-branch libraries (like in NPL) the branch is only for 
members/circulation. All acquisition & cataloguing is done in a unique 
branch.
In other multi-branch library, each branch has it's own cataloguing, 
acquisition... team. So, we need a support for those libraries. I 
propose to have a new systempreference entry, called 
"IndependantBranches" (native english, feel free to suggest something 
better)
When not set, the behaviour is as in 2.2.x
When set, the behaviour becomes :
* in acquisition module, only suggestions made by a user from the same 
branch as the librarian can be accepted/rejected.
* in acquisition module, an order can be modified/recieved/closed only 
by a librarian from the same branch than the librarian that created the 
basket.
* in catalogue module, an item can be modified/deleted/created only by a 
librarian from the same branch as item owner branch
* in members module, a member can be created/modified only by a 
librarian from the branch of the member.

don't need a change in DB, will be in head & backported soon in 2.2.x

*2- OTHER IMPROVEMENTS*
==========================
2-C tracking who does what
Koha will save which librarian creates/modify a biblio, and when (but 
not what he changed ? open question here, as saving what he changed can 
be very complex) Needs a new table in DB, will be in head only.

2-D late orders
in acquisitions, create a new page to see, for a given bookseller the 
order lines that are still not recieved (+ nice printing of this "late 
recieve" list using doNotPrint css rule). The page will be like 
bull/lateissues.pl where you can select a bookseller & see the late 
serial issues he has. the list will show order info, including basket #, 
order date,...) No change in DB, will be in head, backported asap in 2.2.x

2-E serial note
serials management : add a row to the serial table, for librarian notes 
(like "phone call to the bookseller on 06/25, should arrive in 10 days") 
needs a new row in DB. Will be in head, backported in 2.2.x

2-F bookseller history tracker
A tool to follow revivals history (in acquisition & in serials module). 
When you claim a bookseller for a late book or serial, the claim will be 
stored in an history table. Will be in head, not completly analyzed yet, 
feel free to suggest how to do this & what to do exactly.

2-G mail contact
Adding a "mail contact" in branches table. this mail will be shown in 
various places (in OPAC for example) and used on some periodic jobs. 
Needs a row in branches table. Will be in head, backported in 2.2.x

2-H "circulation list"
in serials (subscription creation), the librarian will be able to select 
some users that will recieve the serial issue once after each other. 
this list will be printed by the librarian when recieving an issue. 
(then fasten the printed list to the issue, and make it circulate 
between users). The "reader list" can be ordered by the librarian. In 
OPAC, users can subscribe & unsubscribe to any "subscription circulation 
list". A systempref (CirculationList) will activate or un-activate this 
feature (the OPAC sub/unsub one). will be in head.

2-I "serial issue alert"
With this feature, in serials, a user can subscribe the "issue alert". 
For every issue arrived/missing, a mail is sent to all subscribers of 
this list. The mail warns the user that the issue is arrive or missing. 
Will be in head.

2-J return date calculation
For instance, the return date does not rely on the borrower expiration 
date. A systempref will be added in Koha, to modify return date 
calculation schema :
* ReturnBeforeExpiry = yes => return date can't be after expiry date
* ReturnBeforeExpiry = no  => return date can be after expiry date
will be in head & backported soon in 2.2.x

-- 
Paul POULAIN
Consultant indépendant en logiciels libres
responsable francophone de koha (SIGB libre http://www.koha-fr.org)