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)