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

[Bug 31660] New: MARC preview for authority search results has hidden contents
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '22

14 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31660 Bug ID: 31660 Summary: MARC preview for authority search results has hidden contents Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: kevin.carnes(a)ub.lu.se QA Contact: testopia(a)bugs.koha-community.org When looking at the MARC preview for an authority search result, the preview modal appears empty since the contents are taken from a page with tabs that are hidden by default. Removing the "tab-content" class from the div solves this problem. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 30944] New: Recalls - action buttons to cancel recall on various pages do not work
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '22

14 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30944 Bug ID: 30944 Summary: Recalls - action buttons to cancel recall on various pages do not work 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: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Separated out from bug 30924 - cancel recalls action buttons don't seem to work: 1. Once a recall is made, and checked in: a. On the staff interface item details page > recalls section - selecting from the Actions drop down list/button "Cancel recall and return to Centerville" does nothing. b. However, selecting the tick box and selecting "Cancel selected recalls" works. c. In addition, after you press "Cancel...": - the URL changes to http://127.0.0.1:8081/cgi-bin/koha/recalls/request.pl - clicking on normal (or any other tab gives you the message "The record you requested does not exist ()." - URL is http://127.0.0.1:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber= 2. Once a recall is made, and checked in: . From Circulation > Recalls > Recalls queue: same as 1a and 1b. 3. Once a recall is made, and checked in: . From Circulation > Recalls > Recalls to pull: select "Cancel recall and return to: Centerville: generates this error: DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Data truncated for column 'reason' at row 1 at /kohadevbox/koha/Koha/Object.pm line 170 at /usr/share/perl5/DBIx/Class/Exception.pm line 77 ..... 4. On the patron details > recalls tab page for Henry, selecting Actions > "Cancel recall and return to: Cenetrville" does nothing (same as 1a). Setting up things to test/replicate: 1. Enable recalls: set UseRecalls system preference to 'Use'. 2. Setup rcalls circulation and fines rules: . Recalls allowed (total) = 5 . Recalls per record (count) = 2 . On shelf recalls allowed = 'If any unavailable' . Recall due date interval (day) = 3 . Recall overdue fine amount = 5 . Recall pickup period (day) = 2 3. Checkout an item to a patron: - Patron used: Mary Burton (Midway) - Record used: Programming Perl (biblionumber = 262, one item = 39999000011418, home library = Centerville) 4. Change username/password for a patron, login to the OPAC, and place a recall for the item in step 4. - Patron used: Henry Acevedo (Midway) 5. Check in item for recall with library set to Centerville - confirm recall and transfer. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 32466] New: Add Edition field to bib record created from EDI quote
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '22

14 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32466 Bug ID: 32466 Summary: Add Edition field to bib record created from EDI quote Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: jeremy.evans(a)ukhsa.gov.uk QA Contact: testopia(a)bugs.koha-community.org The EDI Quote messages from our book vendor contains the edition statement but this information is not currently loaded into the autogenerated MARC bib record. e.g. The EDI quote message contains the Edition in element 100. We would like this field mapped to 250$a in the autogenerated bib record. IMD+L+100+:::Seventh edition' Thanks, Jeremy -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 31594] New: Report results count of shown can be incorrect on last page
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '22

14 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31594 Bug ID: 31594 Summary: Report results count of shown can be incorrect on last page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor 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 When a report has more than 20 results, but not a multiple of twenty the final page can have 5 results say, but koha still says: 25 results (20 shown) We should count the number of results for display of shown -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 31653] New: jQuery upgrade broke search button hover effect
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '22

14 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31653 Bug ID: 31653 Summary: jQuery upgrade broke search button hover effect Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Depends on: 29155 Created attachment 141083 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=141083&action=e… Gif showing the intended behavior When we upgrade jQuery I missed an instance of deprecated code: "hover" is no longer an alias for "mouseenter mouseleave" when used with on(). Instead of... $("a").on("hover", function... ...we must use... $("a").on("mouseenter mouseleave", function... This change broken the hover action which is supposed to be triggered when the user's mouse interacts with the "Search" button in the header menu. See attached gif. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29155 [Bug 29155] Upgrade jquery version to 3.6.0 -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 32462] New: Warning in Koha::Item->columns_to_str
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '22

14 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32462 Bug ID: 32462 Summary: Warning in Koha::Item->columns_to_str Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org I see this warning : [WARN] Use of uninitialized value in join or string at /home/koha/src/Koha/Item.pm line 1041. I think it is in Koha::Item->columns_to_str() when more_subfields_xml contains an empty subfield : <record> <leader> a </leader> <datafield tag="999" ind1=" " ind2=" "> <subfield code="q"></subfield> </datafield> </record> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 32414] New: How we can count catalogers detail in biblio by book
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '22

14 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32414 Bug ID: 32414 Summary: How we can count catalogers detail in biblio by book Change sponsored?: --- Product: Koha Version: 19.05 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: muhammadshakir56(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 32274] New: Add option for repeating calendar closings on the nth weekday of the month
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '22

13 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32274 Bug ID: 32274 Summary: Add option for repeating calendar closings on the nth weekday of the month Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: jrobb(a)sekls.org QA Contact: testopia(a)bugs.koha-community.org It would be very helpful if closings could be scheduled to repeat on a specific occurrence of a weekday each month (i.e. repeat closing each 2nd Saturday of every month). My use scenario here is a library that's only open the first Saturday of the month. Currently the fastest way to pull that off is a weekly repeated holiday on Saturday, and then manually placing exceptions each first Saturday which requires ongoing manual upkeep. Double bonus points if it could also limit to a specific month (i.e. repeat closing every 4th Thursday in November). Currently those "Unique" holidays have to be added at the start of each year despite their yearly repetition on a predictable schedule. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 32458] New: memberentry.pl uses both patron and borrower.data
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '22

13 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32458 Bug ID: 32458 Summary: memberentry.pl uses both patron and borrower.data Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, katrin.fischer(a)bsz-bw.de, kyle.m.hall(a)gmail.com While working on a seperate bug I saw in memberenrtygen.tt we will use both borrower_data ( borrower_data.surname ) and patron ( patron.contactname ). Do we need both? Or can we remove borrower_data in favor of patron? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 29958] New: Dateaccessioned is set to todays date if missing when storing an item.
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '22

13 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29958 Bug ID: 29958 Summary: Dateaccessioned is set to todays date if missing when storing an item. Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In the work on bug 23463 the subroutine _set_defaults_for_add was removed in commit 02134d7604a6fc08b88046fde87b6c909de04353. This subroutine was called when a new item was added (in subroutines AddItem and AddItemBatchFromMarc). However, commit 02134d7604a6fc08b88046fde87b6c909de04353 adds this to the store method of Koha::Item : + unless ( $self->dateaccessioned ) { + $self->dateaccessioned($today); + } + I'm guessing this migth have been a mistake, and it should have been added to the new method? The problem here is that libraries that have old items with dateaccessioned NULL will gradually get their database filled with garbage dateaccessioned as the date gets updated whenever the item is issued and therefore will be unable to rely on the accuracy of dateaccessioned. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 41