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

[Bug 20373] New: Add floating toolbar on new acqui/basketgroups.pl page
by bugzilla-daemon＠bugs.koha-community.org 21 Jun '23

21 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20373 Bug ID: 20373 Summary: Add floating toolbar on new acqui/basketgroups.pl page 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: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org On the new page acqui/basketgroups.pl created by ticket 11708, it would be useful to have a floting toolbar. Some librairies (like the BULAC) may have a lot of basket groups and this new useful page is not that ergonomic when scrolling down for the title and sorting lign is not persistent. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 20711] New: Previous fields are not cleared when selecting an authority in notice editor
by bugzilla-daemon＠bugs.koha-community.org 21 Jun '23

21 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20711 Bug ID: 20711 Summary: Previous fields are not cleared when selecting an authority in notice editor Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: david.bourgault(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When choosing an authority for a zone in the bibliographic notice editor, existing fields are not cleared. So if I have a information in the subfields $a $v $9 and I import a authority notice with subfields $a $9 $x, the previous $v value is not cleared. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 32905] New: Fine calculation issue in 22.05
by bugzilla-daemon＠bugs.koha-community.org 21 Jun '23

21 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32905 Bug ID: 32905 Summary: Fine calculation issue in 22.05 Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: enhancement 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 I noticed fine calculation issue in Koha version 22.05 onward and same has been reported byany in 22.11 also. Test plan 1. Configure circulation and fine rules 2. Issue book with backdate 3. Run the cronjob fines.pl 4. Check fine is not calculated 5. Under circulation and fine rules remove default value 0.00 from "overdue fines caps (amount) and give some value to like 100 6. Now run the cronjob fines.pl 7. Check the fine is calculated Now the issue is in earlier versions by default value was nothing under "overdue fines cap (amount)" option so the default value 0.00 in above versions asume fine cap is zero so system does not calculate though everything is configured well. Thanking you -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 31639] New: While receiving items through acquisitions and adding barcode error of "No such Column"
by bugzilla-daemon＠bugs.koha-community.org 21 Jun '23

21 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31639 Bug ID: 31639 Summary: While receiving items through acquisitions and adding barcode error of "No such Column" Change sponsored?: --- Product: Koha Version: 21.11 Hardware: HP OS: Linux Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: sunitabarve(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 141040 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=141040&action=e… Latest intranet-error.log file attached While using Koha 21.11.11, In acquisitions when order is processed and when item is received and if we try to give barcode to the item, GUI page throws error as Error 500 and intranet-error.log shows AH01215: DBIx::Class::Row::store_column(): No such column 'invoicenumber' on Koha::Schema::Result::Item at /usr/share/koha/lib/Koha/Object.pm line 79: /usr/share/koha/intranet/cgi-bin/acqui/finishreceive.pl, referer: http://kohaadmin.ncl.res.in/cgi-bin/koha/acqui/orderreceive.pl?ordernumber=… Several such messages are logged in intranet-error.log mentioning No such column -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 23207] New: Allow automatic checkin/return at end of circulation period
by bugzilla-daemon＠bugs.koha-community.org 20 Jun '23

20 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23207 Bug ID: 23207 Summary: Allow automatic checkin/return at end of circulation period Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- Libraries with materials like Museum Passes, Seed Libraries, and so forth, would like the option have have certain materials checked in/returned from a patron's account on the due date. For example, a library checks out a Museum pass to a patron - it is not a physical item that needs to be returned, but they only want the patron to be able to have one of them during a seven-day period. Right now these items have to be manually checked in at the end of the circ period to remove it from the patron account. An automatic return option via cron job would be helpful. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 58

[Bug 32725] New: Be able to nested sets of conditions in MARC Modification templates
by bugzilla-daemon＠bugs.koha-community.org 20 Jun '23

20 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32725 Bug ID: 32725 Summary: Be able to nested sets of conditions in MARC Modification templates Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)univ-lyon3.fr QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It be useful in MARC Modification templates to have nested sets of conditions : If XXX then If YYYY then If ZZZZ then -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 32724] New: Merge fields / subfields with MARC modification templates
by bugzilla-daemon＠bugs.koha-community.org 20 Jun '23

20 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32724 Bug ID: 32724 Summary: Merge fields / subfields with MARC modification templates Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)univ-lyon3.fr QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be very usefull to be able to merge some fields or subfields, acccording to a specific subfield value, with MARC modification templates. For example, XXX$a= tata XXX$5= number YYY$a = toto YYY$5 = number merge XXX$a and YYY$a in ZZZ$a if XXX$5=YYY$5 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 30586] New: The fallback option when enabling MFA for login doesn't work
by bugzilla-daemon＠bugs.koha-community.org 20 Jun '23

20 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30586 Bug ID: 30586 Summary: The fallback option when enabling MFA for login doesn't work 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 28786 We are missing the shared secret from the fallback display for when a user cannot use a QR scanner when enabling 2FA. I'm not sure how wise it is to display it in full text immediately anyway, perhaps it should be hidden by default.. but as it is, I can't see how the fallback would ever work.. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28786 [Bug 28786] Two-factor authentication for staff client - TOTP -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 30691] New: ElasticSearch Indexer crashes on authtypecode NAME_EVENT
by bugzilla-daemon＠bugs.koha-community.org 20 Jun '23

20 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30691 Bug ID: 30691 Summary: ElasticSearch Indexer crashes on authtypecode NAME_EVENT Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: domm(a)plix.at When GuessAuthTypeCode encounters a record containing tag 147, it returns 'NAME_EVENT'. But in the default Koha installation, 'NAME_EVENT' is not registered in auth_types: select * from auth_types where authtypecode = 'NAME_EVENT'; Empty set (0.000 sec) This causes a bug in Koha/SearchEngine/Elasticsearch.pm:362, because $field is undefined and then passed on to C4::Heading->new_from_field, which dies: Can't call method "tag" on an undefined value at /usr/share/koha/lib/C4/Heading.pm line 71 A simple fix (will be provided soon) is to just ignore and report such cases (as done a few lines further down in Koha/SearchEngine/Elasticsearch.pm, when there is no $authtypecode. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 20478] New: Advance notices: send separate digest messages per branch
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '23

19 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20478 Bug ID: 20478 Summary: Advance notices: send separate digest messages per branch Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org Current behavior for advance_notices.pl is to send one digest message for each borrower. The sender for the message is then set to the branch where the borrower is registered, which can be different from the branch or branches on the issues in question. Desired behavior is that the sender address on the notice message is that of the branch of the issues in question. Thus, the solution is to generate digest messages per branch. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 49