if this prefence is switched on: the document returned in another library than homebranch, the system automaticly transfer the document to his homebranch (with notification for librarian in returns.tmpl) .
switch off : the document stay in the holdingbranch ...
correcting bugs :
- comment C4::acquisition (not using in request.pl).
- correcting date in request.pl
-add the new call of function getbranches in request.pl
- the system check if we don't have another reserv for the document returned, we return the document to his homebranch, ......
- improvement of returns, adapt item reservation , loan rules, and transfer rules ....
new infos displayed :
-Waiting position of borrower on document reserve .
-Follow the document he's in transfert .
-more infos of document are displayed in a specific cell ....
N.B : the old display of reserves infos are only commented, will be removed, if new display is ok for everybody ...
This is to allow a person who is associated with many organisations to choose the one he/she is borrowing an item for
No changes to the issuing code, or the issues table, the associated borrower number is stored in the statistics table
branchreserves : to see reserves for one library (with the branchip selection or librarian preferences)
currenttransfers : show all the transfers are waiting in the library
waitingreservetransfers: show all the book the librarian have to transfer to an another library .
"actions" are bugged, will be corrected .
Seems not to break too many things, but i'm probably wrong here.
at least, new features/bugfixes from 2.2.5 are here (tested on some features on my head local copy)
- removing useless directories (koha-html and koha-plucene)
* synch with rel_2_2. Probably the last non manual synch, as rel_2_2 should not be modified deeply.
* code cleaning (cleaning warnings from perl -w) continued
http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=858
* added a button to cancel issue
* adding checkbox to cancel reserve on the book (checked by default)
* the cancelation reserve is done on reserves done for a given item or for any item
Nelsonville, pls test & confirm it's OK
This 1st commit reorders deeply the circulation module.
The goal is to :
* have something 100% templated/translatable.
* have something easy to read & modify, to say to customers/users : you can define your circulation rules as you want if you accept to look in C4/Circ/Circ2.pm
The circulation now works :
1=> ask for the borrower barcode (as previously)
2=> ask for the item barcode.
3=> check "canbookbeissued". This new sub returns 2 arrays :
- IMPOSSIBLE : if something is here, then the issue is not possible and is not done.
- TOBECONFIRMED : if something is here, then the issue can be donc if the user confirms it.
4=> if TOBECONFIRMED is set : ask for confirmation, loop. if neither are set or confirmation flag is set (2nd pass of the loop), then issue.
The IMPOSSIBLE & TOBECONFIRMED hashs contains :
* the reason of the line. always in capitals, with words separated by _ : BARCODE_UNKNOWN, DEBTS ... as key of the hash
* more information, as value of the hash ( TOBECONFIRMED{ALREADY_ISSUED} = "previous_borrower_name", for example)
This commit :
* compiles
* works on certain situations, not on other
* does NOT issue (the line is # )
* does not check issuing rules depending of # of books allowed / already issued
The next step is :
- check issuing rule.
- extend issuing rule to have a 3D array : for each branch / itemtype / borrowertype = issuing number and issuing length.
This 1st commit reorders deeply the circulation module.
The goal is to :
* have something 100% templated/translatable.
* have something easy to read & modify, to say to customers/users : you can define your circulation rules as you want if you accept to look in C4/Circ/Circ2.pm
The circulation now works :
1=> ask for the borrower barcode (as previously)
2=> ask for the item barcode.
3=> check "canbookbeissued". This new sub returns 2 arrays :
- IMPOSSIBLE : if something is here, then the issue is not possible and is not done.
- TOBECONFIRMED : if something is here, then the issue can be donc if the user confirms it.
4=> if TOBECONFIRMED is set : ask for confirmation, loop. if neither are set or confirmation flag is set (2nd pass of the loop), then issue.
The IMPOSSIBLE & TOBECONFIRMED hashs contains :
* the reason of the line. always in capitals, with words separated by _ : BARCODE_UNKNOWN, DEBTS ... as key of the hash
* more information, as value of the hash ( TOBECONFIRMED{ALREADY_ISSUED} = "previous_borrower_name", for example)
This commit :
* compiles
* works on certain situations, not on other
* does NOT issue (the line is # )
* does not check issuing rules depending of # of books allowed / already issued
The next step is :
- check issuing rule.
- extend issuing rule to have a 3D array : for each branch / itemtype / borrowertype = issuing number and issuing length.
