November 2009 - Koha-bugs - lists.koha-community.org

[Bug 3714] New: holdCancelLength syspref doesn't seem to be used
by bugzilla-daemon＠kohaorg.ec2.liblime.com 15 Feb '10

15 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3714 Summary: holdCancelLength syspref doesn't seem to be used Product: Koha Version: rel_3_0 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: enhancement Priority: P5 Component: Hold requests AssignedTo: gmcharlt(a)gmail.com ReportedBy: jwagner(a)ptfs.com Estimated Hours: 0.0 Change sponsored?: --- The Koha manual for two sysprefs has similar wording: holdCancelLength Specify how many days after a hold has been confirmed, pulled from the shelf and patron contacted before a hold is canceled. Default Value: no value The number you enter represents 'days'. For instance, if you enter '14', then Koha will cancel a hold and change the item's status to 'available' 14 days after the patron has been contacted to pick up the hold. IMPORTANT: This does not take into account a person's place in the hold queue, if they're 200th on the list of holds, and this limit is reached, their hold will be dropped. If you have a big library with a lot of holds, you may want to set this to an insanely high number of days. ReservesMaxPickUpDelay Define the maximum number of days that a user gets to pick up an item on hold before Koha changes the item's status to 'available' (or assigns the hold to the next patron on the holds list) Default Value: 7 Enter a number (the number represents 'days') TIP: If you don't want Koha to automatically 'do' something to items on hold that haven't been picked up, set the value to '0' or leave blank. However, my understanding is that the first one (holdCancelLength) is meant to apply to holds that have NOT been triggered and pulled from the shelf -- it's meant to cancel holds that have been around for a long time without ever getting triggered (such as for on-order items that never come in). See the manual reference to setting it to an "insanely high number of days." The second one is the one that applies after the hold has been triggered, giving the patron X days to come and pick it up. When I did a quick grep on the Koha code, I don't find holdCancelLength anywhere but in the installer files. Can anyone confirm if they've seen it in action? ReservesMaxPickUpDelay is in the various installer scripts, but also used in circ/waitingreserves.pl and it is functional. We've also been doing development with it (see Bug 3474) that is still in process. I would suggest that the holdCancelLength syspref either be removed or implemented. I think the functionality would be useful, and it shouldn't be too hard to write a script that would run as a nightly cron to check through all the existing holds each night, look at the date the hold was placed, run a calculation based on the holdCancelLength syspref, and cancel any that are older than that time period (moving them to the old_reserves table). We may look at doing that when time permits, but if someone else wants to do it earlier, that would be great. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 3

[Bug 3793] New: "Title can't be empty" error while adding item to basket
by bugzilla-daemon＠kohaorg.ec2.liblime.com 12 Feb '10

12 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3793 Summary: "Title can't be empty" error while adding item to basket Product: Koha Version: rel_3_0 Platform: PC OS/Version: Linux - Debian Status: NEW Severity: normal Priority: P5 Component: Acquisitions AssignedTo: ropuch(a)bagno.be ReportedBy: ropuch(a)bagno.be Estimated Hours: 0.0 Change sponsored?: --- When adding new biblio to basket Koha is throwing an error "Title can't be empty" if title starts with double quote. Changing double into single quotes solves the problem. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 1

[Bug 3393] New: Default branches and overdues notices
by bugzilla-daemon＠liblime.com 12 Feb '10

12 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3393 Summary: Default branches and overdues notices Product: Koha Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Notices AssignedTo: nahuel.angelinetti(a)biblibre.com ReportedBy: nahuel.angelinetti(a)biblibre.com Estimated Hours: 0.0 Change sponsored?: --- For the moment, if default rules are set in the overduerules, the script overdues_notices.pl doesn't take care about it. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 7

[Bug 3650] New: problem Label Creator
by bugzilla-daemon＠kohaorg.ec2.liblime.com 12 Feb '10

12 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3650 Summary: problem Label Creator Product: Koha Version: rel_3_2 Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Label printing AssignedTo: henridamien(a)koha-fr.org ReportedBy: laurence.lefaucheur(a)biblibre.com Estimated Hours: 0.0 Change sponsored?: --- Tools -> Label Creator many links (Manage Layouts, Manage Batches, saving of new label layout...) give Koha error : Can't use string ("-1") as an ARRAY ref while "strict refs" in use at /home/koha/versions/integration_3.0.x/C4/Labels/Lib.pm line 445. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 1

[Bug 3537] New: Option as to whether hold charges are determined by patron type or item type
by bugzilla-daemon＠liblime.com 11 Feb '10

11 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3537 Summary: Option as to whether hold charges are determined by patron type or item type Product: Koha Version: rel_3_0 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: enhancement Priority: P5 Component: Hold requests AssignedTo: gmcharlt(a)gmail.com ReportedBy: jransom(a)library.org.nz CC: chris(a)bigballofwax.co.nz Estimated Hours: 0.0 Change sponsored?: --- In our Koha 2 we have it set up so that an adult who uses their child's card to reserve an adult rental item does get charged a hold fee. Likewise an adult who reserves a children's book does not get charged the hold fee. Hold fees are charged depending on the item type, not depending on the patron. In Koha 3.0 it appears that whether a hold fee is charged or not is determined by whether the patron's card being used to place the hold is a child (no hold fee charged) or an adult (hold fee charged). So hold fees are charged depending on the patron type, not the item type. In Koha 2. patron setup we have a hold fee of $1 for almost all patron categories (except for staff, institutions, housebounds and librarys) so kids and adult alike. But reserving kids books, whether an adult or child does not incur hold charges. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 1

[Bug 3595] New: Items seen at checkin should always go to 1st priority hold
by bugzilla-daemon＠kohaorg.ec2.liblime.com 11 Feb '10

11 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3595 Summary: Items seen at checkin should always go to 1st priority hold Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Hold requests AssignedTo: gmcharlt(a)gmail.com ReportedBy: wizzyrea(a)gmail.com Estimated Hours: 0.0 Change sponsored?: --- For full discussion, see: http://stats.workbuffer.org/irclog/koha/2009-09-09#i_299913 Item 1 has 3 items. Patron A has a hold on item 1, Next available. She is first on the list. Library A gets pick list, has item 1a on the list. They ignore it. Patron B places a hold on item 1, next available. Item 1b crosses a scanner gun at library B, item 1b goes to fill hold for Patron B (who is 2nd in line). So to summarize, if an item is on the holds queue report, it will be treated as already allocated for the top person on the holds list. Any other copies scanned will then go to the next person on the hold list. This is incorrect behavior. The pick list (hold queue) should only be a suggestion to the librarians to go grab the book, and should not affect behavior. Other things to watch for when fixing this: - items on the holds queue that are crossing the scanner gun may be going to fill holds that have already been filled (especially for popular items). Processing the item should initiate a transfer for the next first available patron in the queue for that bib (and that may not necessarily be the patron for whom the item was initially picked) - There needs to be some sort of message alerting librarians to the fact that "this hold has already been filled, put this item back on the shelf," should there be no other holds and the hold has been filled in the interim between generation and processing of the pick list. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 3

[Bug 3185] New: Mobile Library/Bookmobile Mode
by bugzilla-daemon＠liblime.com 11 Feb '10

11 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3185 Summary: Mobile Library/Bookmobile Mode Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: galen.charlton(a)liblime.com ReportedBy: nicole.engard(a)liblime.com Estimated Hours: 0.0 I have an idea for a Circ enhancement. In addition to the dropbox mode, why not have a Bookmobile or Mobile Library mode. This would mean that when you check items in at the Bookmobile instead of automatically transferring them back to the home library (as it does now) it keeps the books on the Bookmobile. The way it works now, if you transfer a book to the Bookmobile it's permanent location stays as the main library and it's current location is the mobile library. This is good. But if you keep a book on the mobile library for a period of time you may check it out more than once. If you check a book out and then back in it automatically goes into transfer mode back to the home library - this option would stop that from happening and allow the librarian to decide when the book goes back to the main library. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 5

[Bug 3758] New: Automatic Exchange Rates
by bugzilla-daemon＠kohaorg.ec2.liblime.com 11 Feb '10

11 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3758 Summary: Automatic Exchange Rates Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Acquisitions AssignedTo: paul.poulain(a)biblibre.com ReportedBy: nengard(a)gmail.com CC: nahuel.angelinetti(a)biblibre.com Estimated Hours: 0.0 Change sponsored?: --- I was thinking that it would be great (and very efficient) to have the Currencies & Exchange Rates page in Koha pull data in real time from a currency API. There are a few out there: http://www.programmableweb.com/apitag/?q=currency&sort=date Comments from IRC: [15:24] <pianohacker> nengard: If one of those has a good terms of use that would allow shipping it completely set up, that'd be nice [15:24] <nengard> not sure - would have to read through them all [15:25] <pianohacker> nengard: If the end-user had to set it up manually, that'd still be useful but not as much so [15:25] <nengard> it's just that exchange rates change hourly and so your acq may not have accurate accounting without pulling it in real time -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 3

[Bug 3797] New: The opac 404 page is sent with 200 headers
by bugzilla-daemon＠kohaorg.ec2.liblime.com 10 Feb '10

10 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3797 Summary: The opac 404 page is sent with 200 headers Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: OPAC AssignedTo: chris(a)bigballofwax.co.nz ReportedBy: chris(a)bigballofwax.co.nz Estimated Hours: 0.0 Change sponsored?: --- We should be sending this with 404 headers. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 2

[Bug 3648] New: INSTALLATION / SAX Parser Config Instructions a little cryptic
by bugzilla-daemon＠kohaorg.ec2.liblime.com 10 Feb '10

10 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3648 Summary: INSTALLATION / SAX Parser Config Instructions a little cryptic Product: Koha Version: HEAD Platform: All OS/Version: Linux - Debian Status: NEW Severity: trivial Priority: P5 Component: Installation (command-line installer) AssignedTo: gmcharlt(a)gmail.com ReportedBy: reedwade(a)gmail.com Estimated Hours: 0.0 Change sponsored?: --- PROBLEM: There are some inconsistencies in the SAX parser configuration instructions. The test is clear but how to fix if test fails is cryptic for debian, debian-lenny and ubuntu install instructions saying: "you'll need to edit your ini file" FIX: need to replace cryptic message with instructions that talk about commenting out all but- [XML::LibXML::SAX::Parser] http://xml.org/sax/features/namespaces = 1 from /etc/perl/XML/SAX/ParserDetails.ini assuming that works (seems to on lenny anyhow). ALSO: I'm happy to be assigned to patch this. -reed -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 5