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

[Bug 37518] New: Show brief/full record on bib record detail page
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '24

06 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37518 Bug ID: 37518 Summary: Show brief/full record on bib record detail page Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org The bib record detail page can contain a lot of information, which pushes the Holdings far down the page. I'm thinking perhaps we should have a "Show brief/full record" or "Show more/less information" toggle which by default hides certain information (like notes, subjects, description, etc), and requires a click to show the rest. As we add more information to the display, it's just going to get more and more crowded. I think this would provide a way to provide a maximum of information while also maximizing user experience (UX). -- You are receiving this mail because: You are watching all bug changes.

1 5

[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 36216] New: Hide Show checkouts/charges to guarantor when not necessary
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '24

05 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36216 Bug ID: 36216 Summary: Hide Show checkouts/charges to guarantor when not necessary Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In the patron file (moremember.pl), there is always "Show checkouts to guarantor" and "Show charges to guarantor", even if the library doesn't use the guarantor feature. If AllowStaffToSetCheckoutsVisibilityForGuarantor and AllowPatronToSetCheckoutsVisibilityForGuarantor are both set to "Don't allow", or if the patron has no guarantor, I think the "Show checkouts to guarantor" field should be hidden. Same for AllowStaffToSetFinesVisibilityForGuarantor and AllowPatronToSetFinesVisibilityForGuarantor. If both are set to "Don't allow" or if the patron has no guarantor, the "Show charges to guarantor" should be hidden. I'm thinking especially of academic libraries and special libraries, this is useless information that shows in the patron file. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 37507] New: Koha explodes when trying to apply discount higher than amount of manual invoice
by bugzilla-daemon＠bugs.koha-community.org 04 Aug '24

04 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37507 Bug ID: 37507 Summary: Koha explodes when trying to apply discount higher than amount of manual invoice Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: roman.dolny(a)jezuici.pl QA Contact: testopia(a)bugs.koha-community.org When applying discount higher than amount of manual invoice Koha explodes with a message: "Exception 'Koha::Exceptions::ParameterTooHigh' thrown 'Amount to reduce (100) is higher than original amount (10.000000)' at /usr/share/perl5/Exception/Class/Base.pm line 88". To reproduce: 1. Go to the patron -> accounting 2. Create manual invoice with positive amount (e.g. 10). Click Save. 3. In Transactions tab click 'Apply discount' button and enter discount to apply higher than amount entered in p. 2 (e.g. 100). 4. Koha explodes. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 36003] New: Printing list from OPAC shows "Cookies" when CookieConsent enabled
by bugzilla-daemon＠bugs.koha-community.org 03 Aug '24

03 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36003 Bug ID: 36003 Summary: Printing list from OPAC shows "Cookies" when CookieConsent enabled Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: mirjam.vantieghem(a)etf.edu QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If system preference CookieConsent is set to "Required", the word "Cookies" appears at the bottem left on the last page, under the last result, when printing a list from the OPAC. Funny, but not desirable. Not sure if similar to bug #12260. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[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 36802] New: Add 'status flow' configuration options to catalog concerns
by bugzilla-daemon＠bugs.koha-community.org 02 Aug '24

02 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36802 Bug ID: 36802 Summary: Add 'status flow' configuration options to catalog concerns 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 32435, 35628 Blocks: 34255 With the introduction of catalog concern statuses (bug 35628) and resolutions (bug 32435) we have the foundations for a workflow management solution. I'm envisaging something along similar lines to how Bugzilla manages which statuses are available to pick from at the various stages of the bug workflow. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32435 [Bug 32435] Add resolution types to catalog concerns https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34255 [Bug 34255] Add an enquiry/request/workflow management module https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35628 [Bug 35628] Add additional statuses to catalog concerns -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

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

02 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 36756] New: Fix default action on split update button when editing tickets/catalog concerns
by bugzilla-daemon＠bugs.koha-community.org 02 Aug '24

02 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36756 Bug ID: 36756 Summary: Fix default action on split update button when editing tickets/catalog concerns Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 35657 Just clicking on "update" with ticket resolution status defined does nothing right now, it should update and keep the currently assigned status. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35657 [Bug 35657] Add ability to assign tickets to librarians for catalog concerns -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14