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

[Bug 21074] New: (just a try) Display sparql data from wikidata or bnf
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '22

12 Jan '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21074 Bug ID: 21074 Summary: (just a try) Display sparql data from wikidata or bnf 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: claire.hernandez(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 29861] New: Store and display the date on which a hold was fulfilled
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '22

12 Jan '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29861 Bug ID: 29861 Summary: Store and display the date on which a hold was fulfilled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The patron hold history page shows the date a hold was placed, expired, waiting, or cancelled. But for a hold that was successfully fulfilled, we don't have an easy way of showing the date on which the fulfillment happened. We should create reserves.fulfillmentdate (and old_reserves.fulfillment date) and show that on holdshistory.pl. It's helpful data that users will like to see. Right now, one must rely on either old_reserves.timestamp (which can change) or a rough match on borrowernumber, itemnumber, and timetamp in the old_issues table. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 29613] New: Set focus for cursor to barcode field on course reserves add items and batch add items pages
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '22

12 Jan '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29613 Bug ID: 29613 Summary: Set focus for cursor to barcode field on course reserves add items and batch add items pages Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: eliana(a)flo.org QA Contact: testopia(a)bugs.koha-community.org When clicking on the "Add reserves" or "batch add reserves" buttons in the course reserves module, the cursor focuses on the catalog search bar instead of the box where you scan in the barcodes. I fixed this locally by adding the following to IntranetUserJS: //Switch active cursor to correct box for adding course reserves $(document).ready(function(){ if (window.location.href.indexOf("cgi-bin/koha/course_reserves/add_items.pl") > -1) { $('#barcode').focus(); } }); $(document).ready(function(){ if (window.location.href.indexOf("cgi-bin/koha/course_reserves/batch_add_items.pl") > -1) { $('#barcodes').focus(); } }); -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 29854] New: ES timeout is not configurable
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '22

12 Jan '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29854 Bug ID: 29854 Summary: ES timeout is not configurable Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: major Priority: P5 - low Component: Searching - Elasticsearch Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com Using the sandboxes system I am getting a timeout during the commit request. This is the 'request_timeout' parameter that is defaulting to 30 https://metacpan.org/pod/Search::Elasticsearch::Role::Cxn#request_timeout Setting it to 60 resolved the problem. We should make this value configurable. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 21022] New: Exceptions should skip stringifying if message manually passed
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '22

12 Jan '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21022 Bug ID: 21022 Summary: Exceptions should skip stringifying if message manually passed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Bug 20590 introduced a way to create more useful and testable exception messages. But we should still be allowed to pass manual messages, because we might not have all the information we need to build the stringified version like it proposed. Notably on Koha::Object->store, in which we parse the DBI warning. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 29508] GET /patrons/:patron_id should use Koha::Patrons->search_limited
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '22

11 Jan '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29508 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)|22.05.00,21.11.02 |22.05.00,21.11.02,21.05.08 released in| | Status|Pushed to stable |Pushed to oldstable CC| |andrew(a)bywatersolutions.com --- Comment #10 from Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> --- Pushed to 21.05.x for 21.05.08 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 737] Map of library in search system
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '22

11 Jan '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=737 --- Comment #12 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- Still chewing on this. You wouldn't have to have a separate table to link libraries, shelving locations and maps, if you created specific shelving locations for each library, limiting that location to that library. That would create a long shelving locations table, but it would mean not creating a new table, and if you are limiting to the library, that library is only seeing their shelving locations. Theoretically, that would work. With each unique shelving location code, I would create a separate Authorized Value in a category like SHELVINGMAPS, and use the same shelving location code, and provide the url. In jQuery, I would find the itemnumber, get the shelving code, and then link the map. This would be more ideal if it were built in. Better yet, if I am going to the trouble of creating individual shelving locations for each library, why not take advantage of the icons for that location. It would be great if we could upload our own images for a custom icon, and just define the map in the shelving location. (Unless the icons for shelving locations are actually used somewhere.) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 737] Map of library in search system
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '22

11 Jan '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=737 --- Comment #11 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- Actually, instead of linking specific items to maps, I would suggest that perhaps there could be some way of specifying a specific combination of branch and shelving location in the Authorized Values table that, if matched on a item in the record details, an symbol appears next to the shelving location that patrons can click on to show the map in a model. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 737] Map of library in search system
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '22

11 Jan '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=737 --- Comment #10 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- Would love to see this get some steam behind it again. I could easily see an authorized value category with codes to urls for specific locations in the library. This would work great as we could limit codes to specific libraries. Then we would just need a table linking the item to a code, and make this selectable in item editing. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 737] Map of library in search system
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '22

11 Jan '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=737 Christopher Brannon <cbrannon(a)cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cbrannon(a)cdalibrary.org --- Comment #9 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- Would love to see this get some steam behind it again. I could easily see an authorized value category with codes to urls for specific locations in the library. This would work great as we could limit codes to specific libraries. Then we would just need a table linking the item to a code, and make this selectable in item editing. -- You are receiving this mail because: You are watching all bug changes.

1 0