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

[Bug 25216] New: XSLT can only use HTTP not HTTPS URL.
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '21

12 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25216 Bug ID: 25216 Summary: XSLT can only use HTTP not HTTPS URL. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: Linux Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Hi, At least on Debian libxml doesn't understand https, but only http or local files. It's an issue with more and more systems silently redirecting http to https. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 26457] New: DB DeadLock when renewing checkout items
by bugzilla-daemon＠bugs.koha-community.org 08 Dec '21

08 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26457 Bug ID: 26457 Summary: DB DeadLock when renewing checkout items Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hi, Since it's in a transaction ( https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20086 ) we are seeing deadlock when renewing checkout and items aren't renewed randomly. plack error DBD::mysql::st execute failed: Deadlock found when trying to get lock; try restarting transaction [for Statement "UPDATE issues SET date_due = ?, renewals = ?, lastreneweddate = ? WHERE borrowernumber=? AND itemnumber=?" with P SHOW ENGINE INNODB STATUS; ----------------------- LATEST DETECTED DEADLOCK ------------------------ 2020-09-14 11:09:55 0x7f69b85c0700 *** (1) TRANSACTION: TRANSACTION 19363996, ACTIVE 1 sec fetching rows mysql tables in use 4, locked 4 LOCK WAIT 7 lock struct(s), heap size 1128, 8 row lock(s) MySQL thread id 22449, OS thread handle 140092040718080, query id 38767706 localhost kohaadmin Updating UPDATE issues SET date_due = '2020-09-18 23:59', renewals = '1', lastreneweddate = '2020-09-14T11:09:54' WHERE borrowernumber='93697' AND itemnumber='999735' *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 476 page no 87 n bits 248 index PRIMARY of table `koha`.`issues` trx id 19363996 lock_mode X locks rec but not gap waiting Record lock, heap no 109 PHYSICAL RECORD: n_fields 18; compact format; info bits 0 0: len 4; hex 802713f6; asc ' ;; 1: len 6; hex 000000000000; asc ;; 2: len 7; hex 80000000000000; asc ;; 3: len 4; hex 80016e01; asc n ;; 4: len 4; hex 8008e784; asc ;; 5: len 5; hex 99a7397ec0; asc 9~ ;; 6: len 6; hex 43454e545245; asc CENTRE;; 7: SQL NULL; 8: SQL NULL; 9: len 1; hex 80; asc ;; 10: len 1; hex 80; asc ;; 11: SQL NULL; 12: len 4; hex 5f326b5e; asc _2k^;; 13: len 5; hex 99a6e20000; asc ;; 14: len 4; hex 80000000; asc ;; 15: SQL NULL; 16: SQL NULL; 17: SQL NULL; *** (2) TRANSACTION: TRANSACTION 19363999, ACTIVE 1 sec starting index read mysql tables in use 4, locked 4 4 lock struct(s), heap size 1128, 3 row lock(s) MySQL thread id 22450, OS thread handle 140092041332480, query id 38767702 localhost kohaadmin Updating UPDATE issues SET date_due = '2020-09-18 23:59', renewals = '1', lastreneweddate = '2020-09-14T11:09:54' WHERE borrowernumber='93697' AND itemnumber='583556' *** (2) HOLDS THE LOCK(S): RECORD LOCKS space id 476 page no 87 n bits 248 index PRIMARY of table `koha`.`issues` trx id 19363999 lock_mode X locks rec but not gap Record lock, heap no 109 PHYSICAL RECORD: n_fields 18; compact format; info bits 0 0: len 4; hex 802713f6; asc ' ;; 1: len 6; hex 000000000000; asc ;; 2: len 7; hex 80000000000000; asc ;; 3: len 4; hex 80016e01; asc n ;; 4: len 4; hex 8008e784; asc ;; 5: len 5; hex 99a7397ec0; asc 9~ ;; 6: len 6; hex 43454e545245; asc CENTRE;; 7: SQL NULL; 8: SQL NULL; 9: len 1; hex 80; asc ;; 10: len 1; hex 80; asc ;; 11: SQL NULL; 12: len 4; hex 5f326b5e; asc _2k^;; 13: len 5; hex 99a6e20000; asc ;; 14: len 4; hex 80000000; asc ;; 15: SQL NULL; 16: SQL NULL; 17: SQL NULL; *** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 476 page no 425 n bits 1168 index issuesborridx of table `koha`.`issues` trx id 19363999 lock_mode X waiting Record lock, heap no 52 PHYSICAL RECORD: n_fields 2; compact format; info bits 0 0: len 4; hex 80016e01; asc n ;; 1: len 4; hex 8026df40; asc & @;; *** WE ROLL BACK TRANSACTION (2) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 58

[Bug 17269] New: Library::CallNumber:: LC does not follow LC standards for Area Subarrangments of cataloged maps
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '21

06 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17269 Bug ID: 17269 Summary: Library::CallNumber::LC does not follow LC standards for Area Subarrangments of cataloged maps Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Library::CallNumber::LC is used to generate cn_sort for Library of Congress callnumbers. According to the LC document "Special Instructions and Tables of Subdivisions for Cartographic Materials", in the section 'Area Subarrangments' The document can be found at http://www.loc.gov/catdir/cpso/class_g.pdf; see page 6: "Regions and political divisions within a city or town may be classified with the use of a colon (:) followed by the number 2 or 3, indicating whether the subdivision is (2) geographic or (3) political and a Cutter number for the subdivision. Examples: G4364 California (map city and town number) .L8:2G7 Los Angeles, Griffith Park (classified as a region) G4114 Michigan (map city and town number) .E4:2M4 East Lansing, Michigan State University (classified as a region) G3804 New York State (map city and town number) .N4:3Q4 New York City, Queens (classified as a political division) " When I use Library::CallNumber::LC::Normalize(), 'G4364 .L8:2G7' and 'G4364 .L8' generate entirely different call numbers: Library::CallNumber::LC->normalize("G4364 .L8:2G7") => G4364 .L00008:00002G00007 Library::CallNumber::LC->normalize("G4364 .L8") => G4364 L8 If I'm reading the Library of Congress instructions instructions correctly, I believe that "G4364 .L8:2G7" should generate as "G4364 L8:2G7", which would sort after "G4364 L8", whereas "G4364 .L00008:00002G00007" sorts before "G4364 L8". I'm also filing a bug with the module maintainer: https://github.com/libraryhackers/library-callnumber-lc/issues/10 -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 26834] New: Hiding Branches from the Libraries Link on the OPAC
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '21

06 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26834 Bug ID: 26834 Summary: Hiding Branches from the Libraries Link on the OPAC 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: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org With the introduction of including the "Libraries" link on the OPAC. Bug 13388 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13388) Each library's branch information will display on the OPAC by default. There are library systems that have branches that will not want to be shown on the OPAC, as they are more for the library not for the public to see. Can we have something to be added to the Libraries portion of the Admin module to allow libraries to identify if this branch can be visible on the OPAC. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 24988] New: autorenew_checkouts should default to yes
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '21

06 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24988 Bug ID: 24988 Summary: autorenew_checkouts should default to yes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com TO recreate: Create a new patron Note that 'Allow auto-renewal of items' defaults to 'no' This is a regression caused by bug 24476 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 16551] New: Display the name of lists to the search results at the OPAC
by bugzilla-daemon＠bugs.koha-community.org 04 Dec '21

04 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16551 Bug ID: 16551 Summary: Display the name of lists to the search results at the OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: OPAC Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org This new enhancement will allow to add the name of lists containing a biblio to the search results at the OPAC -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 26051] New: Elasticsearch field local-classification must be sortable
by bugzilla-daemon＠bugs.koha-community.org 04 Dec '21

04 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26051 Bug ID: 26051 Summary: Elasticsearch field local-classification must be sortable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com With Elasticsearch the search field use for sorting by callnumber is "local-classification" (from Koha::SearchEngine::Elasticsearch::QueryBuilder::_convert_sort_fields). So this search field must be sortable in default mappings.yaml. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 38

[Bug 17240] New: Allow processes that rely on background jobs run in Plack mode
by bugzilla-daemon＠bugs.koha-community.org 03 Dec '21

03 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17240 Bug ID: 17240 Summary: Allow processes that rely on background jobs run in Plack mode Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Since Plack mode (PSGI), the processes running with background jobs are broken. Bug 15218 corrected by using CGI mode for concerned pages. This patch proposes to allow running those pages in PSGI mode by disabling background jobs when PSGI is used. -- You are receiving this mail because: You are watching all bug changes.

1 46

[Bug 20754] New: Does table virtualshelfshares need a unique index on shelfnumber+borrowernumber+invitekey?
by bugzilla-daemon＠bugs.koha-community.org 03 Dec '21

03 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20754 Bug ID: 20754 Summary: Does table virtualshelfshares need a unique index on shelfnumber+borrowernumber+invitekey? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Coming from bug 11943 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 26536] New: "Writeoff selected" seems deduct old unpaid fines first
by bugzilla-daemon＠bugs.koha-community.org 03 Dec '21

03 Dec '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26536 Bug ID: 26536 Summary: "Writeoff selected" seems deduct old unpaid fines first Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: mishravk79(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Hello In version 20.05.04 Writeoff selected fine tab does not write off only selected instead it applied on oldest unpaid fine first. Test Plan 1. Two returned book/s with unpaid fine 2. Try to write off lasted returned book with "Writeoff selected" 3. You will observe fine deducted from oldest unpaid book. Vinod -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 46