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

[Bug 23532] New: AutoCreateAuthorities create authority only headings
by bugzilla-daemon＠bugs.koha-community.org 23 Feb '24

23 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23532 Bug ID: 23532 Summary: AutoCreateAuthorities create authority only headings Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: gveranis(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The problem: We have enable AutoCreateAuthorities and also enable BiblioAddsAuthorities and when we insert values for tag 650 , we get authorities only with 150$a filled and not other subfields. I found that on C4/Biblio.pm lines 549 - 555 map { $authfield->add_subfields( $_->[0] => $_->[1] ) if ( $_->[0] =~ /[A-z]/ && $_->[0] ne "a" && C4::Heading::valid_bib_heading_subfield( $authority_type->auth_tag_to_report, $_->[0] ) ); } $field->subfields(); Koha try to copy subfields to the new authority record. BUT the condition C4::Heading::valid_bib_heading_subfield( $authority_type->auth_tag_to_report, $_->[0]) return false. Because the $authority_type->auth_tag_to_report has value of 150 and not 650 as file C4/Heading/MARC21.pm declared. if we set on file C4/Heading/MARC21.pm also the value '150' => { auth_type => 'TOPIC_TERM', subfields => 'abvxyz', subject => 1 }, (valid based on https://github.com/Koha-Community/Koha/blob/master/installer/data/mysql/en/…) then it works , but I am not sure if it is valid to set there new fields. or better solution could be $authority_type->auth_tag_to_report take right value in condition. Could anyone propose the best solution ? Thanks, George Veranis -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 24421] New: Generated authorities are missing subfields
by bugzilla-daemon＠bugs.koha-community.org 23 Feb '24

23 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24421 Bug ID: 24421 Summary: Generated authorities are missing subfields Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In bug 21826 the intent was to only add allowed subfields to generated authorities, however, the code uses the authority tag instead of the biblio tag - there is no mapping for these, so correct subfields are ignored To recreate: 1 - Enable the sysprefs AutoCreateAuthorities BiblioAddsAuthorities CatalogModuleRelink 2 - Open a record with a subject heading with a subdivision and add a new subfield, or add a new unauthroized heading to a record and save it e.g. 650$aChess$xOpenings$vFiction. 3 - Save the record, note the created authority and that field is linked 4 - Save the record again and note the authority number changes 5 - Find and view the authority linked to the record 6 - The record is for 'Chess', not Chess openings' 7 - Search authorities for 'Chess' - note duplicated records -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 25261] New: Multiple parts handling - confirmation alert
by bugzilla-daemon＠bugs.koha-community.org 23 Feb '24

23 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25261 Bug ID: 25261 Summary: Multiple parts handling - confirmation alert Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.field(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Koha already has a field in the item record to identify multi-part material. Materials specified (bound volume or other part) or 952$3. When there is a value in this field (e.g. 2) Koha will prompt you at checkout and checkin with a message dialog which says: Note about the accompanying materials: 2 This is helpful but can be missed by library staff. This enhancement takes this one step further to introduce a confirmation box to acknowledge that the parts have been checked on issue and return. This prevents staff from proceeding before checking the item in their hands. The reason for this is to prevent arguments with library patrons that they did not originally take all the parts or that they did not return all the parts. For example, a CD with an accompanying booklet or a string quartet with 4 parts. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 239

[Bug 33664] New: Should we allow cancelling orders while the basket is closed?
by bugzilla-daemon＠bugs.koha-community.org 23 Feb '24

23 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33664 Bug ID: 33664 Summary: Should we allow cancelling orders while the basket is closed? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: caroline.cyr-la-rose(a)inlibro.com, michaela.sieber(a)kit.edu This is a workflow question: At the moment cancelling an order line from the basket summary page is only possible, while the basket is open. For standing orders this means it's always possible, while it's not for other types of orders. There is now 2 ways to cancel the order: Option A: * Reopen the basket * Cancel the order * Close the basket + Less clicks than option B - All unreceived order lines will switch status unnecessarily (ordered - new - ordered) - The basket close date will reset to today's date Option B: * Create a new shipment * 'Fake' an invoice, for example it could be named: Cancellations * Use the cancelling options from the list of pending orders + Close date remains the same + Only the cancelled order line will change status - More clicks and not really convenient Now the question: Is there a strict reason why we should not permit cancelling from a closed order? The closed order lines will still show in the second table below. We could also add a hint on the cancellation date. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33

[Bug 30232] New: Acquisition logged in user performance
by bugzilla-daemon＠bugs.koha-community.org 23 Feb '24

23 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30232 Bug ID: 30232 Summary: Acquisition logged in user performance Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Some acquisition methods can take borrowernumber or a Koha::Patron->unblessed. When called with logged in user, sometimes in a loop, performance will be better if fetching Koha::Patron of logged in user only once. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 35312] New: When circulation is blocked by noissuecharge, total of outstanding charges can be wrong
by bugzilla-daemon＠bugs.koha-community.org 22 Feb '24

22 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35312 Bug ID: 35312 Summary: When circulation is blocked by noissuecharge, total of outstanding charges can be wrong Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor 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: clemens.tubach(a)kit.edu, gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com, michaela.sieber(a)kit.edu When some debit types are excluded from blocking circulation (noissuecharge), the total on the checkouts page will exclude them, although they are still outstanding. * Set systempreference noissuecharge to 5 * Add a new debit type: TEST * amount: 6.00 * Can be manually ivoiced? Yes * Include in noissuescharge? No (don't check it) * Go to any patron account without open fines/fees * Create a manual invoice for TEST of 6.00 * Verify fine total shows as 6 and you can still checkout * Add another manual invoice of type Manual fee of 6.00 * Verify the table shows a total of 12.00 * Verify you can no longer checkout On the checkouts tab you'll see a message: Charges: Patron has outstanding charges of 6.00. Checkouts are BLOCKED because fine balance is OVER THE LIMIT The amount is wrong. The outstanding charges are 12.00 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 34145] New: Patron search broken
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '24

21 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34145 Bug ID: 34145 Summary: Patron search broken Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: justin(a)juicetoon.xyz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com This is my console output: Uncaught TypeError: Cannot read properties of undefined (reading 'branchname') at render (members-home.pl:2483:76) at datatables.min_23.0500000.js:56:435 at b.fnGetData (datatables.min_23.0500000.js:50:221) at B (datatables.min_23.0500000.js:55:141) at Ha (datatables.min_23.0500000.js:63:1) at P (datatables.min_23.0500000.js:67:433) at vb (datatables.min_23.0500000.js:78:98) at datatables.min_23.0500000.js:75:167 at i (datatables.min_23.0500000.js:73:338) at Object.success (datatables.min_23.0500000.js:74:40) And this is where branchname appears in members-home.pl: in { "data": "library_id", "searchable": true, "orderable": true, "render": function( data, type, row, meta ) { let library_name = libraries_map[data].branchname if( !singleBranchMode && data == logged_in_library_id ) { return "<span class=\"currentlibrary\">" + escape_str(library_name) + "</span>"; } else { return escape_str(library_name); } } } It seems that this bug may be related: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31421 Though it says a fix was pushed to stable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 33982] New: Error 500 on OPAC on recently edited records
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '24

21 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33982 Bug ID: 33982 Summary: Error 500 on OPAC on recently edited records Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: Linux Status: NEW Severity: critical Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: joseanjos(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Since I update from version 22.05 to 22.11, every record I edit on Staff interface, can't be searched anymore on OPAC. (ERROR 500) I've updated to 23.05 but the problem persists. On Staff interface I can search it. opac-error.log: [Mon Jun 12 10:25:29.952048 2023] [cgi:error] [pid 6040] [client XX.XX.XX.XX:48968] AH01215: Use of uninitialized value in hash element at /usr/share/koha/opac/cgi-bin/opac/opac-detail.pl line 678.: /usr/share/koha/opac/cgi-bin/opac/opac-detail.pl [Mon Jun 12 10:25:29.952589 2023] [cgi:error] [pid 6040] [client XX.XX.XX.XX:48968] AH01215: DBIC result _type isn't of the _type Branch at /usr/share/koha/opac/cgi-bin/opac/opac-detail.pl line 678.: /usr/share/koha/opac/cgi-bin/opac/opac-detail.pl [Mon Jun 12 10:25:29.987521 2023] [cgi:error] [pid 6040] [client XX.XX.XX.XX:48968] End of script output before headers: opac-detail.pl I've checked for permissions issues but everything looks OK. Rebuild Zebra: koha-rebuild-zebra -b -f -v koha looks OK, no errors -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 24430] New: Remove C4::Biblio::CountBiblioInOrders
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '24

21 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24430 Bug ID: 24430 Summary: Remove C4::Biblio::CountBiblioInOrders Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement 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 Using the DBIC relationship with aqorders and count, we can get rid of it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 43

[Bug 35147] New: Add IDs to Shibboleth text on OPAC login page
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '24

21 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35147 Bug ID: 35147 Summary: Add IDs to Shibboleth text on OPAC login page 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org So the message can be customised for the library using OPACUserJS. -- You are receiving this mail because: You are watching all bug changes.

1 17