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

[Bug 33239] New: Add the ability to run borrowers-force-messaging-defaults.pl only on a specified message name
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '23

18 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33239 Bug ID: 33239 Summary: Add the ability to run borrowers-force-messaging-defaults.pl only on a specified message name 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 It would be helpful to run misc/maintenance/borrowers-force-messaging-defaults.pl with a speficied message name. So apply default category value only on some message (like Item_due) and keep patron choice for the others. Values of message name can be found in : https://git.koha-community.org/Koha-community/Koha/src/branch/master/instal… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 28995] New: Add --added_after to writeoff_debts.pl
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '23

18 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28995 Bug ID: 28995 Summary: Add --added_after to writeoff_debts.pl 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: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Depends on: 27049 writeoff_debts.pl currently supports --added_before to make it work on fines added before a given date. It would be nice if we could also tell it to work on fines added after a given date, with --added_after. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27049 [Bug 27049] Add a script to bulk writeoff debts -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 27736] New: When an unauthenticated user goes to report a problem, the problempage URL will be lost
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '23

18 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27736 Bug ID: 27736 Summary: When an unauthenticated user goes to report a problem, the problempage URL will be lost 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: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org When an unauthenticated user goes to report a problem, they're first prompted to login, then they have to click the "report a problem" link a second time and now the value of the $referer variable is going to be opac-user.pl and not the original page. Steps to recreate: - enter a KohaAdminEmailAddress and set OPACReportProblem to Allow - as an unauthenticated user visit any page other than your account (opac-user.pl) e.g. search results (opac-search.pl) or a bib detail (opac-detail.pl) - select the "report a problem" link at the bottom - you're interrupted by the user login process, complete your authentication - you land on the user account page opac-user.pl - if you select "report a problem" again now, the "problempage" value on the form will be some form of "/cgi-bin/koha/opac-user.pl..." and not the original page you attempted to report There is a work around—users can return to where they originally had the problem and click "report a problem" there, but that's not intuitive nor user friendly. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 35171] New: runreport.pl cronjob should optionally send an email when the report has no results
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '23

18 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35171 Bug ID: 35171 Summary: runreport.pl cronjob should optionally send an email when the report has no results Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Some libraries would like to know that a report was run overnight, even if there were no results. We should allow this as an optional feature. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 33050] New: More args for misc/cronjobs/runreport.pl
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '23

18 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33050 Bug ID: 33050 Summary: More args for misc/cronjobs/runreport.pl 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 Add to script misc/cronjobs/runreport.pl args for CSV : separator and quote -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 23935] New: Sharing on Social Media looks wrong
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '23

18 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23935 Bug ID: 23935 Summary: Sharing on Social Media looks wrong Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org When I tried sharing a record on Facebook, while I was writing the post, it showed the cover, but looked like it was including information from the login panel. Then when it was posted, it didn't include the cover or the login info. It did include the record title, but the image was the catalog banner/logo. Something isn't quite right with the social media posting. At least with Facebook. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 34514] New: opac-showmarc.pl does not handle UNIMARC well
by bugzilla-daemon＠bugs.koha-community.org 16 Dec '23

16 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34514 Bug ID: 34514 Summary: opac-showmarc.pl does not handle UNIMARC well Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org opac-showmarc.pl calls $record->as_xml. We see in other places using XSL transformation that MARC flavor should be sent. Looks like encoding fails when a "real" UTF-8 character is used. For example É Bug 29333 fixed catalogue/showmarc.pl. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 20936] New: Holds History for patrons in OPAC
by bugzilla-daemon＠bugs.koha-community.org 15 Dec '23

15 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20936 Bug ID: 20936 Summary: Holds History for patrons in OPAC 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: eveal(a)mckinneytexas.org QA Contact: testopia(a)bugs.koha-community.org I think it would be very nice to add the "Hold History" for the patrons to access in the OPAC. I don't know if the bug to add it to the staff site would be useful or not but here it is. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14919 Ed -- You are receiving this mail because: You are watching all bug changes.

1 164

[Bug 25965] New: Create SIP2 client daemon with HTTPS API endpoint
by bugzilla-daemon＠bugs.koha-community.org 15 Dec '23

15 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25965 Bug ID: 25965 Summary: Create SIP2 client daemon with HTTPS API endpoint Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: lmstrand(a)gmail.com I am trying to pass messages to a sip server using a new endpoint I created in swagger/openApi. This endpoint uses the guidelines described here: http://biblstandard.dk/rfid/dk/rfid_sip2_over_https.htm The idea is to get rid of the tunneling/VPN implementations that we use, and use HTTPS instead to pass sip messages back and forth inside an XML. The Apache server handles the HTTPS stuff so I don't have had to worry about that so far when communicating with the REST api, hence the SipOHttp naming in my module. At the moment I can send the XML POST messages formed like in the linked guideline to the endpoint (XML wrapped SIP2 message to .../api/v1/sipmessages/). The api forwards the body content of the request to my module Koha::REST::V1::SipOHttp. The module validates and parses the contents of the XML message, extracts the information about the sip server the message is intended to (using the "login:" parameter inside the XML) and the sip message itself (inside the <request></request> variable). Then the module passes the sip message on to the sip server using IO:Socket::INET. My problem is that the sip server closes the connection after this first SC device login message has been passed and the response has been read back in my module: (from sip2.log) ..... [INFO] [undef](a)10.0.3.217: OUTPUT MSG: '941' C4::SIP::Sip::write_msg /home/koha/Koha/C4/SIP/Sip.pm (187) [DEBUG] SIPDEVICE(a)10.0.3.217: raw_transport: uname/inst: 'SIPDEVICE/SIPDEVICE' C4::SIP::SIPServer::raw_transport /home/koha/Koha/C4/SIP/SIPServer.pm (174) [DEBUG] SIPDEVICE(a)10.0.3.217: EOF returned on read C4::SIP::SIPServer::read_request /home/koha/Koha/C4/SIP/SIPServer.pm (349) [INFO] SIPDEVICE(a)10.0.3.217: raw_transport: shutting down C4::SIP::SIPServer::raw_transport /home/koha/Koha/C4/SIP/SIPServer.pm (178) So I need a way to keep this socket connection open for other future messages. Without touching the sip server's code itself, the only solution I can come up with is a proxy server that handles and passes on the REST api's incoming messages to sockets and keeps each invidual socket connection open to specific instances of the sip servers (I suppose the sip server itself ends the connections when needed so you wouldn't have to worry about it in the sender's end). Another solution would be to build a new api separate from the swagger/Openapi one. Like an all-in-one solution that deals with the requests and keeps tabs on the open socket connections. Let me know if you have ideas regarding this. Ps. I'm a trainee in Koha Suomi (Finland) so excuse me if the description of my problem is a bit vague and lacks some correct terms used. I'm happy to fill in any details I've left out. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 46

[Bug 23303] New: When uninstalling a plugin we don't call any form of 'unload'
by bugzilla-daemon＠bugs.koha-community.org 15 Dec '23

15 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23303 Bug ID: 23303 Summary: When uninstalling a plugin we don't call any form of 'unload' 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org We currently clean up the filesystem and run through the 'uninstall' method from the plugin in point during the uninstall process. We don't however, ever, unload the module code from memory and this may result in plack environments leaking memory. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5