Here is a proposed list of functions necessary to generate arbitrary circulation interfaces. Comments requested. Is this an appropriate forum for programming discussion? Program API for circulation interfaces: ==================== getpatroninformation ==================== Subroutine returns a hash reference with all patron information. Can be called with either borrowernumber or cardnumber. ($env, $patroninformation) = getpatroninformation($env,$borrowernumber,$cardnumber) ============= currentissues ============= Returns a hash reference (itemnumber => duedate) ($env, $currentissues) = currentissues($env, $borrowernumber); ================== getiteminformation ================== Subroutine returns a hash reference with all item information. Can be called with either itemnumber or barcode. ($env, $iteminformation) = getiteminformation($env,$itemnumber,$barcode) ============ findborrower ============ Subroutine returns an array reference containing a list of borrowernumbers that match $key. $key could be a cardnumber or a partial last name. ($env, $borrowernumber) = findborrower($env, $key) ========= issuebook ========= This subroutine may or may not generate additional questions that must be answered. ($env, $itemnumber, $rejected, $question, $questionnumber, $defaultanswer, $responses) = issuebook($env,$borrowernumber,$barcode) Subroutine must handle errors, some that block issuing, some that must be approved before issuing. If $rejected is not null, it will contain a message detailing the reason for rejection. Possible responses are listed below, prepended with 'Error:'. Alternatively, $rejected may just be '-1' in which case the issue should be rejected with no message displayed to the user. This might happen if the answer to a question resulted in a rejection. Error: Invalid barcode _____ Error: Invalid borrowernumber ____ Error: Item is restricted [$item->{'notforloan'}==1] Error: Item withdrawn [$item->{'withdrawn'}==1] Error: Restricted Item (and borrower not allowed to check out) [$item->{'restricted'}==1] Error: Reference item not for loan [$item->{'itemtype'} eq 'REF'] [Circulation::Renewals::renewstatus] Error: Issued to this patron, no renewals. If $question is not null, it will contain a YesNo question that should be asked. $defaultanswer will contain 'Y' or 'N'. $questionnumber will contain a unique integer for each question that might be asked. Interface code will generate a hash reference ($responses) with the responsees to each question asked and then recall issuebook() until the issue is accepted or rejected. Question: Already issued to this patron and reserved to ___, renew? default N Question: Already issued to this patron, renew? [$newdate=C4::Circulation::Renewals::renewbook()] Question: Already issued to patron ___, mark as returned? [returnrecord()] calculate any charges [calc_charges()] and [createcharge()] ========== returnbook ========== Subroutine for returning a book. $message may contain an arbitrary message to display to the user (maybe should be an array reference for multiple messages?). ($env, $itemnumber, $borrowernumber, $message, $overduefees) = returnbook($env,$barcode) Message: Reserved for collection at branch _______ Calculate any overdue fees (not in current Circulation code) [UpdateStats]
* Tonnesen Steve <tonnesen@cmsd.bc.ca> [010111 08:20]:
Here is a proposed list of functions necessary to generate arbitrary circulation interfaces. Comments requested.
Is this an appropriate forum for programming discussion?
I think so for now, if we start generating heavy traffic, we can start up a koha-dev list or something og the like
Program API for circulation interfaces:
==================== getpatroninformation ==================== Subroutine returns a hash reference with all patron information. Can be called with either borrowernumber or cardnumber.
($env, $patroninformation) = getpatroninformation($env,$borrowernumber,$cardnumber)
I think maybe this might need to return reference to a hash of flags also. For example if the borrower owes a substantial amount of money, or a has a note on his/card a warning should be displayed. Depending on the flag different actions should be taken also. The flags could be included in patroninformation though I guess, eg $patroninformation->{'flags'}=\%flags;
============= currentissues =============
Returns a hash reference (itemnumber => duedate)
($env, $currentissues) = currentissues($env, $borrowernumber);
Yep seems fine
================== getiteminformation ==================
Subroutine returns a hash reference with all item information. Can be called with either itemnumber or barcode.
($env, $iteminformation) = getiteminformation($env,$itemnumber,$barcode)
Looks good
============ findborrower ============
Subroutine returns an array reference containing a list of borrowernumbers that match $key. $key could be a cardnumber or a partial last name.
($env, $borrowernumber) = findborrower($env, $key)
Ditto
========= issuebook =========
This subroutine may or may not generate additional questions that must be answered.
($env, $itemnumber, $rejected, $question, $questionnumber, $defaultanswer, $responses) = issuebook($env,$borrowernumber,$barcode)
Subroutine must handle errors, some that block issuing, some that must be approved before issuing.
If $rejected is not null, it will contain a message detailing the reason for rejection. Possible responses are listed below, prepended with 'Error:'. Alternatively, $rejected may just be '-1' in which case the issue should be rejected with no message displayed to the user. This might happen if the answer to a question resulted in a rejection.
Error: Invalid barcode _____ Error: Invalid borrowernumber ____ Error: Item is restricted [$item->{'notforloan'}==1] Error: Item withdrawn [$item->{'withdrawn'}==1] Error: Restricted Item (and borrower not allowed to check out) [$item->{'restricted'}==1] Error: Reference item not for loan [$item->{'itemtype'} eq 'REF'] [Circulation::Renewals::renewstatus] Error: Issued to this patron, no renewals.
If $question is not null, it will contain a YesNo question that should be asked. $defaultanswer will contain 'Y' or 'N'. $questionnumber will contain a unique integer for each question that might be asked. Interface code will generate a hash reference ($responses) with the responsees to each question asked and then recall issuebook() until the issue is accepted or rejected.
Question: Already issued to this patron and reserved to ___, renew? default N Question: Already issued to this patron, renew? [$newdate=C4::Circulation::Renewals::renewbook()] Question: Already issued to patron ___, mark as returned? [returnrecord()]
calculate any charges [calc_charges()] and [createcharge()]
Yeah this looks like a good way to do it, i think that maybe we could pass to issuebook the patroninformation, rather than the borrowernumber. That way we wouldnt have to check certain flags again like the borrower owing more than x dollars, which prohibits issues. That is assuming that u call getpatroninformation before issuebook. Just a thought.
========== returnbook ==========
Subroutine for returning a book. $message may contain an arbitrary message to display to the user (maybe should be an array reference for multiple messages?).
($env, $itemnumber, $borrowernumber, $message, $overduefees) = returnbook($env,$barcode)
Message: Reserved for collection at branch _______ Calculate any overdue fees (not in current Circulation code)
[UpdateStats]
Hmm I think $message will need to be an array reference. If an item has been marked as lost, and then is returned, maybe a message might be wanted to alert the librarian to the fact that this was marked as a lost item. As well as the Reserve notice. Looking good so far, I think those are the main circulation functions. In fact issuing and returning items are the only things you cant do with the web interface. The other things contained in circ like renewals, and payments are there because of speed issues. It would be good to build them into the API tho as well, whether ppl choose to implement them in their circulation interface can be up to them. Thanks for your work on this Steve, Chris -- Chris Cormack Programmer 025 500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
Hi everybody, I need to install koha on a low-in-resources computer (an i486 with 690Mb HDD). Since I cannot install all the development packages to properly configure CDK, cdkperl (perl recompile as far as I know) I am unable to succesfully install the koha files. Could someone point me to places where such binaries are available. I don't know how to build rpm binaries, don't know how to write the spec file, etc. Do you know where to download binaries from for: cdk, cdkperl, perl-DBI, DBD, AuthenDBI? All those modules are in tar.gz format on a cpan.org & www.vexus.ca site. Thanks for any info
On Fri, 12 Jan 2001, Chris Cormack wrote:
==================== getpatroninformation ==================== I think maybe this might need to return reference to a hash of flags also. For example if the borrower owes a substantial amount of money, or a has a note on his/card a warning should be displayed. Depending on the flag different actions should be taken also. The flags could be included in patroninformation though I guess, eg $patroninformation->{'flags'}=\%flags;
Right. Missed the flags. Okay, looking for flags currently being used to get an idea for what is needed here: CHARGES -- Accounts::checkaccount() returns $amount > 0 LOST -- card reported as lost NOTES -- displays contents of borrowers->borrowernotes field ODUES -- checkoverdues() returns > 0 WAITING -- Main::checkwaiting() returns nowaiting>0 Some of these can be handled with a simple message returned that the interface module must display to the user (ie Patron owes $6.40, Patron's card reported lost, Patron Note: _____). Overdues and Waiting might need to be treated more carefully. In tk-perl, I like displaying item information in a table format, so returning a simple message with a list of overdues or reserves would be less than ideal. It might be sufficient to have the flags display interface be capable of showing a message and an optional list of items? That doesn't quite work. For reserves, holdingbranch is important, but not for overdues. Could return an array listing which fields of the item should be displayed for the message.
========= issuebook =========
Yeah this looks like a good way to do it, i think that maybe we could pass to issuebook the patroninformation, rather than the borrowernumber. That way we wouldnt have to check certain flags again like the borrower owing more than x dollars, which prohibits issues. That is assuming that u call getpatroninformation before issuebook. Just a thought.
Makes good sense. The interface code will certainly want to call getpatroninformation before starting issuing books.
The other things contained in circ like renewals, and payments are there because of speed issues.
Aren't renewals handled by the issuebooks() call? If the book is already issued to the user, it will get renewed. Steve.
The other things contained in circ like renewals, and payments are there because of speed issues.
Aren't renewals handled by the issuebooks() call? If the book is already issued to the user, it will get renewed.
Ahh true, yeah that'll work nicely. Chris -- Chris Cormack Programmer 025 500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
participants (3)
-
Benedykt P. Barszcz -
Chris Cormack -
Tonnesen Steve