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

[Bug 3638] New: Status of hold not changed when item checked in via SIP2 Interface
by bugzilla-daemon＠kohaorg.ec2.liblime.com 16 Feb '10

16 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3638 Summary: Status of hold not changed when item checked in via SIP2 Interface Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: SIP2 AssignedTo: joe.atzberger(a)liblime.com ReportedBy: colin.campbell(a)ptfs-europe.com Estimated Hours: 0.0 Change sponsored?: --- When an Item is returned via SIP2 the unit is being correctly alerted that it is required for a hold and the details of the hold. However unlike a normal check in the status of the hold does not reflect that the item has been captured. This causes problems in the work flow, forcing sip2 checked in items to be manually checked in before the hold is shown as waiting or in transit to pickup location. -- 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 3449] New: Filtering tags by valid borrowernumber incorrectly displays error message
by bugzilla-daemon＠liblime.com 16 Feb '10

16 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3449 Summary: Filtering tags by valid borrowernumber incorrectly displays error message Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Tools AssignedTo: galen.charlton(a)liblime.com ReportedBy: oleonard(a)myacpl.org Estimated Hours: 0.0 Change sponsored?: --- As originally reported as part of Bug 2693, if you use the "filter" form on the tags review page to filter on a valid borrowernumber the page will display an error message even as it returns results: "ERROR: No match for user (51). FILTER REQUIRES BORROWERNUMBER (not name)." -- 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 3654] New: Authorized Values Page Edits
by bugzilla-daemon＠kohaorg.ec2.liblime.com 16 Feb '10

16 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3654 Summary: Authorized Values Page Edits Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: System Administration AssignedTo: nengard(a)gmail.com ReportedBy: nengard(a)gmail.com Estimated Hours: 0.0 Change sponsored?: --- The Authorized Values page says that's it's just for cataloging - but Authorized Values are used for more than that now - so this page needs some text editing. -- 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 7

[Bug 3652] New: XSS vulnerabilities
by bugzilla-daemon＠kohaorg.ec2.liblime.com 16 Feb '10

16 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3652 Summary: XSS vulnerabilities Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: critical Priority: P5 Component: Templates AssignedTo: mjr(a)ttllp.co.uk ReportedBy: mjr(a)ttllp.co.uk Estimated Hours: 0.0 Change sponsored?: --- Koha has several XSS attack opportunities. There are two approaches to fixing this: 1. identify and ESCAPE="HTML" (or URL or JS) all places in the templates which are vulnerable; 2. set default_escape => "HTML" in C4::Output and identify the places in the templates which require ESCAPE="0" (unescaped) output. 1 (default permit) seems less secure than 2. 2 will break some things in the short term. This seems like a generalisation of bug #2690. -- 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 3586] New: errors pages are sent with HTTP 200 OK header
by bugzilla-daemon＠kohaorg.ec2.liblime.com 15 Feb '10

15 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3586 Summary: errors pages are sent with HTTP 200 OK header Product: Koha Version: rel_3_2 Platform: All URL: http://koha/cgi-bin/koha/errors/404.pl OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Browser compatibility AssignedTo: joe.atzberger(a)liblime.com ReportedBy: mjr(a)ttllp.co.uk CC: oleonard(a)myacpl.org, gmcharlt(a)gmail.com Estimated Hours: 0.0 Change sponsored?: --- All of the errors scripts send results back to clients with HTTP 200 OK header. This leads to some clients taking incorrect actions. To see the fault, try curl -I http://koha/cgi-bin/koha/errors/404.pl and look at the first line of output. Looks to me like C4::Output::output_html_with_http_headers doesn't pass status code to C4::Output::output_with_http_headers and the errors scripts don't send error codes anyway. -- 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

[Bug 3622] New: basket group
by bugzilla-daemon＠kohaorg.ec2.liblime.com 15 Feb '10

15 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3622 Summary: basket group Product: Koha Version: rel_3_2 Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Acquisitions AssignedTo: paul.poulain(a)biblibre.com ReportedBy: paul.poulain(a)biblibre.com Estimated Hours: 0.0 Change sponsored?: --- When closing a basket (basket.pl op=attachbasket) : - don't display a basketgroup list if there are no basketgroup available - fill the basketgroup name (case of a new basketgroup) with the basket name (pre-typed by default) - on 1st line: Attach to <basketgrouplist> or create new basketgroup <input> - "close basketgroup ..." => "close basketgroup" - add an option to leave basket ungrouped - "Change basketgroup" => "OK" basketgroup.pl - add an option to delete a basketgroup (while unclosed) - calculating of the baskettotal does not work for ungrouped baskets - add a date on basketgroup to know when a basketgroup has been closed - add basketgroup owner (ie: creator) - add basketgroup: not javascript anymore. Opens a page, with the new basketgroup, and the list of ungrouped baskets. The librarian can drag and drop, then save. A button let choose "close & print", that print the PDF, and close the basketgroup. After saving, return to basketgroup page. - basketgroup name => must be unique (check for duplicate) - on the main basketgroup page, just have a list of basketgroups : Name / status / date closed / basketgroup owner / reopen - print - modify - delete (reopen & print only available if closed, modify & delete only available if not closed) -- 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 4

[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 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