January 2018 - Koha-bugs - lists.koha-community.org

[Bug 19752] New: Improve authentication response in offline_circ/ service.pl
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19752 Bug ID: 19752 Summary: Improve authentication response in offline_circ/service.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: alex.arnaud(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com offline_circ/service.pl currently returns a "200 OK" HTTP status with a "Authentication failed" string. We need a valid status code in this case (401). We also need a nocookie option in this script. We added a test button in Koct FF extention that check if the entered login/password are correct. But if the user is currently authenticated on Koha, the script will use the cookie authentication which can be misleading. With nocookie parameter set to true, only the login/password will be checked. Patch is coming -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 19638] New: False positives for 'Update SQL' button
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19638 Bug ID: 19638 Summary: False positives for 'Update SQL' button Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org bug 17898 tries to help users identify reports affected by the move of marcxml to the biblio_metadata table, however, the auth_header table still uses the column name 'marcxml' and so reports as needing updated though it doesn't -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 19706] New: Item search: Unsupported format html
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19706 Bug ID: 19706 Summary: Item search: Unsupported format html Change sponsored?: --- Product: Koha Version: 17.05 Hardware: PC OS: Linux Status: NEW Severity: critical Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: elias.dehler(a)thulb.uni-jena.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl After upgrading to 17.05.06.000 Item search no longer works, as long as screen is selected. CSV and Barcodes file working as intended. When screen is the selected output you get the following software error: Unsupported format html at /usr/share/koha/intranet/cgi-bin/catalogue/itemsearch.pl line 41. Steps to reproduce: 1. upgrade to 17.05.06.000 2. in the intra: search -> item search 3. leave everything as it is and click search -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 19970] New: Revise change of bug 19413 to work better for translations
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19970 Bug ID: 19970 Summary: Revise change of bug 19413 to work better for translations Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 19413 Created attachment 70481 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=70481&action=ed… screenshot de-DE Bug 19413 moved the buttons in the cataloguing plugins to the top, this doesn't work well for translations where the terms 'cancel' and 'ok' can be longer. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19413 [Bug 19413] Move the location of the Ok and cancel buttons to the 008 cataloguing builder -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 20090] New: Missing Script Statement for Novelist Select on Some Record Displays in OPAC
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20090 Bug ID: 20090 Summary: Missing Script Statement for Novelist Select on Some Record Displays in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: techservspec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org This applies to libraries using Novelist Select enhanced content in their OPAC. Items with a UPC code but no ISBN are causing a script error (a call to an undefined function) in the opac-detail display. This is preventing custom jQuery/scripts from running (as well as keeping any content from Novelist from displaying). The cause: Not all of the conditionals for Novelist in opac-detail.tt are checking for UPCs, most notably the statement that adds the script for using Novelist. This can result in calls to non-existent functions. To test (note that you must subscribe to Novelist Select): 1. If your library does not use the patron ratings feature, activate it for the purposes of this test. 2. Display a record in the opac that has an ISBN number. Note that the rating option has 5 stars to choose from. 3. Display a record that does not have an ISBN in the 020 field, but has a upc (or other code) in the 024 field. The rating option will display as 5 radio buttons and a "rate it" button (the radio buttons are normally replaced by stars via a built-in jQuery script). -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 19671] New: Circulation wizard / issues_stats.pl does not populate itemtype descriptions correctly
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19671 Bug ID: 19671 Summary: Circulation wizard / issues_stats.pl does not populate itemtype descriptions correctly Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1 - Run the circulation wizard with itemtypes as columns, shelving locations as rows - display on screen 2 - Note all itemtype values are blank 3 - Switch rows/columns - same issue -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 19204] New: Fines in days restriction calculation is not taking calender into account
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19204 Bug ID: 19204 Summary: Fines in days restriction calculation is not taking calender into account Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When using the fines in days feature, the restrictions will be calculated without taking holidays into account. So the restriction can end in the middle of a period the library is closed. To test: - Set finescalendar to 'not including days the library is closed' - Set a circulation condition with no fine/maxfine, but fine days and max fine days instead - Check out an item with a due date in the past - Check the item in and verify the restriction date - Clean the restriction - Add holidays to your calendar on the calculated restriction date - Check the item out again with the same due date in the past - Check in the item again - Verify the calculated restriction end date now is the same and a holiday. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 40

[Bug 19579] New: PatronSelfRegistrationEmailMustBeUnique does not prevent duplicates when using PatronSelfRegistrationVerifyByEmail
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19579 Bug ID: 19579 Summary: PatronSelfRegistrationEmailMustBeUnique does not prevent duplicates when using PatronSelfRegistrationVerifyByEmail Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: baselibrary.consortium(a)nhs.net QA Contact: testopia(a)bugs.koha-community.org With PatronSelfRegistrationVerifyByEmail set to Require and PatronSelfRegistrationEmailMustBeUnique set to Consider a patron can still self register many times using the same email address. Test case 1. Patron submits self registration form using the same email address 3 times 2. Patron receives 3 verification emails 3. Patron clicks on 3 verify token URLs 4. Staff client now shows the 3 patrons 5. Patron logs into 3 accounts on OPAC 6. Patron cannot change personal details because email address already exists -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 19712] New: Fix command line options of delete_records_via_leader.pl
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19712 Bug ID: 19712 Summary: Fix command line options of delete_records_via_leader.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz 1. This code: 56 if ( $help || !$confirm ) { 57 ... 70 exit(); 71 } means that unless you specify --confirm you will never be able to run the script - it will just print the usage and exit. That means --test is useless. 2. The script has both of these options: -c --confirm: Script will do nothing without this parameter -t --test: Test mode, does not delete records. What happens if you specify both? Or none? I think test mode should be the default (when no options are specified) and changes to the database should only be done when --confirm is specified. This would be consistent with other scripts, I think. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 19972] New: Holds to pull (pendingreserves.pl) should honor syspref " item-level_itypes"
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '18

24 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19972 Bug ID: 19972 Summary: Holds to pull (pendingreserves.pl) should honor syspref "item-level_itypes" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor.grousset(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Test plan: 1. Set syspref "item-level_itypes" to "specific item" 2. Create a hold on a record with one item 3. Change the document type of the item 4. Check that the item edition page and the record page show 2 different types. 5. Go to /cgi-bin/koha/circ/pendingreserves.pl 6. Check that the displayed type is the item one 7. Set syspref "item-level_itypes" to "biblio record" 8. Go to /cgi-bin/koha/circ/pendingreserves.pl 9. See that the displayed type is the item one. When the sysopref says "record" This is the bug. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24