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

[Bug 16919] New: Problems with cart
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '19

04 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16919 Bug ID: 16919 Summary: Problems with cart Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The cart deletion does not seem to always delete the cart. Users have reported that after adding items to a cart, clearing the cart (from the results screen) and then adding an item from the results all previous items reappear. I have recreated this, but not with steps I can recreate. Basically if you add and remove items enough from cart you start to see oddities. Try various combintations of adding/removing and going forward/backward in browser and new results. I also noted in testing I ended up with two cookies, one pointing to the base URL and one pointing to baseurl/cgi-bin/opac-main.pl -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 20224] New: Account restrictions still allow hold / reservation to be placed.
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '19

04 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20224 Bug ID: 20224 Summary: Account restrictions still allow hold / reservation to be placed. Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: r.delahunty(a)arts.ac.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When an item becomes more than 7 days overdue we send the ODUE2 email which also places a restriction on the user account. Self issue, auto-renewal, issuing all fail / is not possible, but the user can still place a reservation / hold and have the item pulled from the shelf or intercepted on return, and sent in transit to a library for collection. The user can retrieve the item from the (publicly accessible) reservations shelf, read it in the library and dump the item somewhere in the library. Users whose accounts are restricted should not be able to place holds / reservations. Ray Delahunty University of the Arts London -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 19002] New: Invoice filters "Shipment date (From):" and " Billing date (From):" don't start with date selected
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '19

04 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19002 Bug ID: 19002 Summary: Invoice filters "Shipment date (From):" and "Billing date (From):" don't start with date selected Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: jsterben(a)umich.edu QA Contact: testopia(a)bugs.koha-community.org When filtering invoices using "Search filters" on left side of screen, setting the "From:" shipment date does not include results from that date, effectively functioning as a "greater than" limiter instead of a "greater than or equal to" limiter. I (and, I expect, most users) would expect "greater than or equal to" functionality. This condition was confirmed true both when only "shipment dates" were used to limit as well as when another criterion (I chose "vendor") was selected. URL parameters show correct passing of date value in "shipmentdatefrom". The same conditions and results are true with "Billing date (From):" and its parameters. Maybe a simple wording change is the fix, ("From" to "After"), though typical usage of date limiters includes, not excludes, the date selected in results sets. It is unknown if this condition existed in earlier releases. VERIFY (using Shipment Date): 1) Using any means at your disposal, learn of any valid shipmentdate value in aqinvoices 2) GO TO: Home > Acquisitions > Invoices 3) Set a limiter for "Shipment date (From:)" using that valid shipmentdate 4) Observe that no results from that date appear in the results OTHER DETAILS: Koha 17.05.01.000 on Ubuntu 14.04 with MySQL 5.5.55, installed and updated via packages. Observed in Chrome 59.0.* and Firefox 53.0.* -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 18909] New: Enable the maximum zebra records size to be specified per instance
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '19

04 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18909 Bug ID: 18909 Summary: Enable the maximum zebra records size to be specified per instance Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The default for Zebra is to not return results where the record size is greater than 1045 KB ( 1 MB ). Some libraries need to increase this ceiling, but it may come at a cost with z39.50 compatibility with other services. For that reason, we should make this setting configurable on a per-instance basis. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 21447] New: Inventory lists incorrectly sorted
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '19

04 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21447 Bug ID: 21447 Summary: Inventory lists incorrectly sorted Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org In the real world, I've found the cn_sort field does not always have correct values, and the same itemcallnumber field may have different cn_sort values. My theory is that the method for generating cn_sort changed at some point, and that has created inconsistencies in the creation of cn_sort value, especially in Koha databases that have existed for a long period of time. -- I received reports that the lists generated by /cgi-bin/koha/tools/inventory.pl and shown on screen weren't sorted by call number. That led me to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19021 and that seemed to solve the problem as it resorted the data table by the call number. However, when using the "Export to CSV file" option, the data was still not sorted correctly, and thus was incompatible with the data table shown on screen, which defeats the purpose of doing an inventory without a scanned barcode file. -- This can be solved by running touch_all_items.pl. However, this is not a systematic solution. Perhaps we should do a database revision that runs ModItem for all items. This seems problematic for databases with large numbers of items, but it seems a good idea to provide a systematic solution instead of requiring people to run touch_all_items.pl if they notice the problem. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 16487] New: Cataloging/Authority search: add link to number of times used
by bugzilla-daemon＠bugs.koha-community.org 03 Feb '19

03 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16487 Bug ID: 16487 Summary: Cataloging/Authority search: add link to number of times used Change sponsored?: --- Product: Koha Version: 3.20 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: theod(a)lib.auth.gr QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When cataloging an authority-controlled field, the librarians get a popup window by clicking at the "...", where they search a term and get a list of results. In that list there is a separate column (titled "used") where one gets the number this term is used in records. It would be very helpful for the librarian if this number was a LINK that displayed these specific records, so that he/she may select the proper authority. This functionality exists already in simple authority search (Home › Authorities › Authority search results), so if accepted by the community, implementing it in the popup window too would be fairly easy. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 18614] New: Add useful CSS classes to the *detail.pl pages
by bugzilla-daemon＠bugs.koha-community.org 03 Feb '19

03 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18614 Bug ID: 18614 Summary: Add useful CSS classes to the *detail.pl pages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: mtj(a)kohaaloha.com QA Contact: testopia(a)bugs.koha-community.org It would be really useful to add more CSS classes to the various *detail.pl pages more details to come... -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 16627] New: Patron Update Organization
by bugzilla-daemon＠bugs.koha-community.org 03 Feb '19

03 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16627 Bug ID: 16627 Summary: Patron Update Organization Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Patron updates need to be grouped by library (when you can see them all) and should show the date the request was made (how long has it been sitting there?). Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 15766] New: A batch should be given a description.
by bugzilla-daemon＠bugs.koha-community.org 03 Feb '19

03 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15766 Bug ID: 15766 Summary: A batch should be given a description. Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: Heinrich.Hartl(a)email.de QA Contact: testopia(a)bugs.koha-community.org A batch should be given a description. I find it hard to remember what for I compiled that list. In batch administration the description should be displayed. -- You are receiving this mail because: You are watching all bug changes.

1 77

[Bug 17186] New: Error duplicate bibliography when saving new record
by bugzilla-daemon＠bugs.koha-community.org 03 Feb '19

03 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17186 Bug ID: 17186 Summary: Error duplicate bibliography when saving new record Change sponsored?: --- Product: Koha Version: 3.18 Hardware: PC OS: Windows Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: hien.pham(a)dlcorp.com.vn QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When I saving new record in module catalog, Koha automatic created two record in database with same data. This error is not full time, it just happens to some records in Koha. Koha version: 3.18.04 Please help me for check this error. Thank you! -- You are receiving this mail because: You are watching all bug changes.

1 1