Hourly Loans RFC
From Koha Wiki
Koha > Technical > Development > RFCs
Koha > Technical > Development > RFCs > Koha components for RFCs > Library System Modules RFCs > Circulation RFCs
Koha > Technical > Development > RFCs > Koha version targeted RFCs > RFCs not targeted at a particular Koha version
|Developed by:||Ian Walls, ByWater Solutions.|
|Bug number:||Bug 737 Map of library in search system|
|Work in progress repository:||No URL given.|
|Description:|| Koha 3.2's circulation loans are currently measured only in units of days. However, because some libraries, especially academic libraries, perform loans that are measured in minutes or hours, particularly for course reserves and short loans, it is necessary to modify Koha to perform all circulation and related transactions in units of minutes
The main changes will include:
This RFC is similar to the unimplemented RFC for Hourly circulation policies from Koha 3.2
This specification changes the loan system in Koha to support loan, grace periods and fine periods measured in hours. As part of this project, it will be possible to create circulation policies in terms of hours and minutes. These policies will work in tandem with new calendars that allow the library to express their opening and closing times in hours.
The following policies will be expressible in the smart-rules.pl with a combination of numeric field and unit dropdown selector.:
The possible units will be:
COMMENT: This paragraph should probably be revised for clairty. I cannot imagine any combination of hours and days which should not be convertable to minutes with no remainder. The only place I can see for rounding to be needed is in the caculation of fines when a patron returns an item, for example, 90 seconds overdue, which is addressed in this RFC below. -chris_n
COMMENT: Logic (such as unit conversion) should probably be left to the controller portion of the code rather than pushed off to the display portion (thinking MVC here). Perhaps it would be better to use an ajax type call to change/convert units in the view. -chris_n
Additional circulation policies will become necessary to handle “rounding” of due times, since the library does not necessarily wish an item checked out for 1 day to be due exactly 1440 minutes later.
Options for rounding should include:
Another policy is necessary to handle the situation when calculated due times occur when the library is closed. Either the material is:
Examples of possible circulation situations and policies:
a material with a 3 hour loan period is checked out 1 hour before the library closes.
a material with a 2 hour loan period is checked out at 2:23pm
A material with a 3 day loan period is checked out at 3:33pm on Monday
Overdue fine calculation
Overdue fine calculation will behave essentially the same way, except it will occur more frequently than the typical ‘once a night’ scheduling of files.pl. This script, or it’s updated analog, could be scheduled to run on cron every minute, or a daemon could be written to handle fine calculation on demand.
After an item’s calculated due time plus the defined grace period, overdue fines will begin to accrue. The charges will increment by the fine amount again after the fine charging interval. Fine accrual will stop after the maximum fine value has been reached, or the item is returned, or the item is marked lost.
If a library utilizes patron suspension periods instead of or in addition to fines, the borrower will be marked as suspended for the defined suspension period after the item’s due time plus defined grace period
Display of due dates and times
When displaying due dates and times in the OPAC, both the date and time will be shown. If the due time is at the library’s open or closing hour for that day, the time can be suppressed from displaying with a system preference.
In the staff client, due times will need to be shown not only in Circulation, but also in Patron reading history and the item’s circulation history.
Defining Library Hours
The library calendar should be moved from Tools to Administration, since it shall now be so vital to the library’s circulation policies.
Staff shall continue to be able to specify the specific branch they wish to work with.
The calendar shall have two different kinds of events that can be specified: Library Hours, and Exceptions. Library Hours shall include an opening time and a closing time. When configuring Library Hours, the staff members shall have the option to set the hours to repeat daily or weekly, until a specified end date. Future edits to Library Hours that were initial set up as repeating shall offer the option to propagate the changes to the rest of the pattern, or apply only to this day.
Exceptions shall be either one-off events or annually repeated (like holidays). They will specify an alternate opening and closing time for the day that will overwrite the value configured in Library Hours. Future changes to the Library Hours for that day will not effect the Exception unless the Exception is deleted
The system shall need to be able to take in Holds Effective Dates and Expiry Dates in periods of minutes, as well, to match the circulation options. This would allow students to indicate that a hold is not useful to them before their class gets out at 4pm, or after they have to take their mid-terms at 2:30pm. The time specification is optional, and will default to the library’s opening time for that date if it is not specified.
Similarly, Koha would need to be able to take in units other than days for automatically canceling expired or unfilled holds.
The current cronjob for messaging is set up to process advanced notices and overdues nightly, and queue those messages for processing by a script that runs hourly (by default). For loan periods of less than 1 day, we'd need something quicker to make notices worthwhile. For example, it would be nice to send patrons an SMS message (if they opt in for that) 5 minutes before a reserve book is due.
This means that either the message script will need to run every minute or so, or there needs to be a daemon. If the cron runs every minute, and goes off the EXACT due time for generating notices, the circulations will be spread out enough through the day to prevent there being any kind of pile-up (where the script takes longer than 1 minute to run). This could be a problem if a batch circulation was done for some reason...
A daemon would provide more on-demand messaging, but would be one additional process to initiate and maintain for Koha.
An additional wrinkle comes with allowing users to define how far in advance they receive notices; having the option of '3 days' in advance doesn't do any good for a 2 hour loan, just as '5 minutes' in advance doesn't work for a 3 day loan. Either they'd need to be able to set both "longer term" and "shorter term" advanced notice preferences, or have the time in advance removed as an option for their configuration.
This could easily be it’s own development project.
Several existing system preferences need to be changed in light of the new loan periods