[IMPORTANT] transfer & reserve problem/question (bug ?)
Hello world, The status of a book, in the result list of a query is given by the items.onloan (952$q in marc21 if I don't mind). This field let Koha know wether the book is available or issued. If 952$7 -notforloan-, $1 -itemlost-, $0 -wthdrawn is set, the status will be correctly displayed. but what if a book is being transfered and/or reserved. Actually, the book is displayed as "available", which is wrong (unless i've missed some parameter someone will point ;-) ) imo, a book being transfered should display "1 item being transfered from X to Y" (in staff interface) and "Not available" (in opac) a book reserved should be displayed likely. The SAN-OP has this feature in it's specific 3.0 version, running live since 1 year now, and it display those information. How could we reintroduce this behaviour ? the easiest solution would be, in to introduce a test for that in C4/Search.pm/sub searchResults. what do you think of this solution ? Another one would be to have new fields in items table, to store a transfer or a reserve, but I think it's too complex. -- Paul POULAIN BibLibre SARL Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19
Hi Paul, On 1/25/08, Paul POULAIN <paul.poulain@free.fr> wrote:
Hello world,
World sends greetings. :)
imo, a book being transfered should display "1 item being transfered from X to Y" (in staff interface) and "Not available" (in opac) a book reserved should be displayed likely.
Sounds reasonable, but this definitely should be configurable, as some libraries may want to also have to OPAC explicitly say "in transit" or "in transit from X to Y" rather than just a plain "not available".
The SAN-OP has this feature in it's specific 3.0 version, running live since 1 year now, and it display those information.
How could we reintroduce this behaviour ? the easiest solution would be, in to introduce a test for that in C4/Search.pm/sub searchResults. what do you think of this solution ? Another one would be to have new fields in items table, to store a transfer or a reserve, but I think it's too complex.
I don't think a new items field would necessary, as the transfer status should be derivable from branchtransfers and the request status from reserves. Perhaps there should be an omnibus function in C4::Circulation or C4::Items that checks all of the various fields that describe an item's status and returns a nicely structured result that in turn can be parsed for display in the staff or OPAC search results. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709
Galen Charlton a écrit :
Hi Paul,
On 1/25/08, Paul POULAIN <paul.poulain@free.fr> wrote:
Hello world,
World sends greetings. :)
imo, a book being transfered should display "1 item being transfered from X to Y" (in staff interface) and "Not available" (in opac) a book reserved should be displayed likely.
Sounds reasonable, but this definitely should be configurable, as some libraries may want to also have to OPAC explicitly say "in transit" or "in transit from X to Y" rather than just a plain "not available".
Definetly... I think we should click on the "pause" button, and think a little bit more about what we want for Koha. I've seen dozens of sysprefs, some of them being very important & interesting & some of them being, imho, too much. We face the risk to build what we call in french a "gaz plant", to mean "something so complex to manage that it's unuseable" Displaying "Not available" or "in transit" or "in transit from X to Y" is typically the king of thing that we should avoid to put in a syspref. We should decide how to have it & explain any customer what it means to have zillions of sysprefs.
I don't think a new items field would necessary, as the transfer status should be derivable from branchtransfers and the request status from reserves. Perhaps there should be an omnibus function in C4::Circulation or C4::Items that checks all of the various fields that describe an item's status and returns a nicely structured result that in turn can be parsed for display in the staff or OPAC search results. What do you call an omnibus function ? Could you give some more details about how you would implement it ?
thx by advance -- Paul POULAIN BibLibre SARL Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19
Hi, On 1/29/08, Paul POULAIN <paul.poulain@free.fr> wrote:
Galen Charlton a écrit :
I don't think a new items field would necessary, as the transfer status should be derivable from branchtransfers and the request status from reserves. Perhaps there should be an omnibus function in C4::Circulation or C4::Items that checks all of the various fields that describe an item's status and returns a nicely structured result that in turn can be parsed for display in the staff or OPAC search results. What do you call an omnibus function ? Could you give some more details about how you would implement it ?
What I have in mind is a single function (or perhaps a family of functions) that, given an itemnumber, would consult all of the relevant items, circulation, and orders columns (e.g., items.lost, items.wthrawn, items.damaged, items.onloan, items.notforloan, etc.), and return a nice Perl structure or object representing the item's complete current circulation and acquisitions status. All of the messy details of determining the actual status would be encapsulated there. I realize, of course, that there already exist functions that cover parts of this, e.g., C4::Items::GetItemStatus, C4::Circulation::CanBookBeIssued, etc., but at present there doesn't seem to be an easy way to guarantee that the code that determines whether an item can be issued is in sync with the code that determines if an item shows up as available in the OPAC. Given such a function, additional functions would be needed to translate the status structure into a human-readable message; as part of designing this, we could perhaps consolidate the sysprefs that control display of item status into a simpler syspref or templating mechanism. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709
participants (2)
-
Galen Charlton -
Paul POULAIN