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

[Bug 32463] New: Embed analytical items into bibliographic records export
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '24

07 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32463 Bug ID: 32463 Summary: Embed analytical items into bibliographic records export Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz In misc/export_records.pl add to bibliographic records export the analytical items (linked by fields 773/461). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 24449] New: SIP2 - too_many_overdue flag is not implemented
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '24

07 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24449 Bug ID: 24449 Summary: SIP2 - too_many_overdue flag is not implemented Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com While the field is in the SIP patron object, it is never populated. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 17489] New: Allow Koha plugins to have translations
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '24

07 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17489 Bug ID: 17489 Summary: Allow Koha plugins to have translations 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We should come up with a way of allowing plugin templates to be translatable so installations using multiple languages can have the plugin displayed in the selected language. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 29816] New: Document patron emailer cronjob
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '24

07 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29816 Bug ID: 29816 Summary: Document patron emailer cronjob Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org misc/cronjobs/patron_emailer.pl was introduced by Bug 16149, but as far as I can tell it is not documented in the manual. Sorry if I missed it. I'd say documenting this is extra important, since it is a cool feature that is not visible from the Koha GUI (but see also Bug 27452.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 28122] New: Remove old syslog config from SIPconfig.xml
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '24

06 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28122 Bug ID: 28122 Summary: Remove old syslog config from SIPconfig.xml Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org It used to be that logging for the SIP2 server was configured in SIPconfig.xml: <server-params min_servers='1' min_spare_servers='0' log_file='Sys::Syslog' syslog_ident='koha_sip' syslog_facility='local6' /> The last 3 lines are the relevant ones. These lines are still present in the template file for Debian packages: https://git.koha-community.org/Koha-community/Koha/src/branch/master/debian… Then "Bug 15253: Add Koha::Logger based logging for SIP2" added logging based on log4perl for SIP2. But as far as I can see, the remnants of syslog config makes the SIP2 server not run properly. To reproduce: If you are on a dev setup (e.g. kohadevbox), copy the log4perl template to the standard location: $ sudo cp kohaclone/debian/templates/log4perl-site.conf.in /etc/koha/log4perl-site.conf.in Create a new site, called siptest: $ sudo koha-create --create-db siptest Verify that /etc/koha/sites/siptest/log4perl.conf has a section for SIP: log4perl.logger.sip = DEBUG, SIP log4perl.appender.SIP=Log::Log4perl::Appender::File log4perl.appender.SIP.filename=/var/log/koha/siptest/sip.log log4perl.appender.SIP.mode=append log4perl.appender.SIP.layout=PatternLayout log4perl.appender.SIP.layout.ConversionPattern=[%d] [%p] %m %l %n log4perl.appender.SIP.utf8=1 Enable and start the SIP2 server: $ sudo koha-sip --enable siptest Enabling SIP server for siptest - edit /etc/koha/sites/siptest/SIPconfig.xml to configure $ sudo koha-sip --start siptest Use ps to check if the SIP server is actually running: $ ps aux | grep SIPServer siptest+ 20084 0.0 0.0 18708 1732 ? S 15:40 0:00 daemon --name=siptest-koha-sip --errlog=/var/log/koha/siptest/sip-error.log --stdout=/var/log/koha/siptest/sip.log --output=/var/log/koha/siptest/sip-output.log --verbose=1 --respawn --delay=30 --pidfiles=/var/run/koha/siptest --user=siptest-koha.siptest-koha -- perl /home/vagrant/kohaclone/lib/C4/SIP/SIPServer.pm /etc/koha/sites/siptest/SIPconfig.xml vagrant 20294 0.0 0.0 12780 968 pts/0 R+ 15:44 0:00 grep SIPServer This output means the daemon is running, but not the SIP-server itself. Edit /etc/koha/sites/siptest/SIPconfig.xml and remove these three lines: log_file='Sys::Syslog' syslog_ident='koha_sip' syslog_facility='local6' Then restarte the SIP2 server: $ sudo koha-sip --restart siptest Then run ps again: $ ps aux | grep SIPServer siptest+ 20383 0.0 0.0 18708 196 ? S 15:44 0:00 daemon --name=siptest-koha-sip --errlog=/var/log/koha/siptest/sip-error.log --stdout=/var/log/koha/siptest/sip.log --output=/var/log/koha/siptest/sip-output.log --verbose=1 --respawn --delay=30 --pidfiles=/var/run/koha/siptest --user=siptest-koha.siptest-koha -- perl /usr/share/koha/lib/C4/SIP/SIPServer.pm /etc/koha/sites/siptest/SIPconfig.xml siptest+ 20385 42.0 8.2 382120 169104 ? S 15:44 0:01 perl /usr/share/koha/lib/C4/SIP/SIPServer.pm /etc/koha/sites/siptest/SIPconfig.xml siptest+ 20390 0.0 7.6 382120 156460 ? S 15:44 0:00 perl /usr/share/koha/lib/C4/SIP/SIPServer.pm /etc/koha/sites/siptest/SIPconfig.xml vagrant 20392 0.0 0.0 12780 968 pts/0 S+ 15:44 0:00 grep SIPServer Lines that contain "perl /usr/share/koha/lib/C4/SIP/SIPServer.pm /etc/koha/sites/siptest/SIPconfig.xml" indicate the actual SIP2 server is running. I think what needs to be done is: - Remove the 3 syslog-related lines from etc/SIPconfig.xml and debian/templates/SIPconfig.xml - Add a note to the release notes that the 3 lines need to be removed from SIPconfig.xml fles that are in active use PS! I have not looked deeply at *why* those three config lines makes the SIPserver fail to run, just that removing them fixes the problem. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 33305] New: Standing orders: Allow to link received item to another bibliographic record on receive
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '24

05 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33305 Bug ID: 33305 Summary: Standing orders: Allow to link received item to another bibliographic record on receive 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: michaela.sieber(a)kit.edu At the moment we use standing orders for multi-volume and series ordering mostly. The order is placed on the set or traced series record. When a part of the series is delivered and received, the order line will still be linked to the set records. This makes all acquisition information appear on the set record, instead of the parts. If you are using items, you can use the "attach item" feature, to change it to the record of the part, but this means a lot of additional clicks. It will also not work if you are not creating items in acq. It would be nice, if you could link the received order line to the correct part as part of the receiving process. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 34576] New: wrong information about use of 942 in unimarc
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '24

03 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34576 Bug ID: 34576 Summary: wrong information about use of 942 in unimarc Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org In https://koha-community.org/manual/23.05/en/html/cataloging.html#added-entry… it is said that 942$2,$6 and $c is used in UNIMARC installation in the same way as MARC21 It is not the case in my (unimarc) library, and it is not what is written in the wiki https://wiki.koha-community.org/wiki/Holdings_data_fields_(9xx) Is it hardcoded somewhere in Koha ? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 32435] New: Add resolution types to catalog concerns
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '24

03 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32435 Bug ID: 32435 Summary: Add resolution types to catalog concerns Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 31028 It would be nice to have a descriptive resolution text for different standard resolutions to catalog problems reported via the new catalog concerns feature. We're envisaging using the authorized values system to populate a drop down of resolutions available. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31028 [Bug 31028] Add 'Report a concern' feature for patrons to report concerns about catalog records -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 65

[Bug 15854] New: Possible race condition for sending renewal notices
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '24

01 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15854 Bug ID: 15854 Summary: Possible race condition for sending renewal notices Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Renewal notices are sent as digests - all renewed items are collected in one e-mail that is sent out with the process_messagequeue. We have a library, where sometimes this doesn't work. Instead of one single e-mail notice to the patron for one 'process_messagequeue' interval, multiple renewal notices are generated. The majority of e-mails is generated correctly. Looking at the code, this is about how it works: - AddRenewal is exectuted per item and calls - SendCirculationAlert which calls - C4::Message->find_last_message to help decide if a new notice has to be generated or an existing one can be amended In order to test this, you need: - EnhancedMessagingPreferences - Check-out notice checked for the patron you test with - RenewalSendNotice activated - A notice called RENEWAL As I see no problem in the logic so far, I think it could be a race condition where find_last_message doesn't find an existing notice (yet)? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 24007] New: Koha::Account::non_issues_charges is badly named
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '24

01 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24007 Bug ID: 24007 Summary: Koha::Account::non_issues_charges is badly named 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org The non_issues_charges method name suggests you will be returned a set of charges (Account::Lines) which would block a patrons ability to check out items. In fact, it returns a 'balance' of such charges but includes outstanding credits in the calculation. We should either rename the method to clarify it's use or update the method to return the expectation given it's naming. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10