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

[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 14 Dec '23

14 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 14 Dec '23

14 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

[Bug 31731] New: Offer user a dropdown of authorized values instead of a text field in preferences
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '23

14 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31731 Bug ID: 31731 Summary: Offer user a dropdown of authorized values instead of a text field in preferences Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: System Administration Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, testopia(a)bugs.koha-community.org Depends on: 31730 If we're asking the user to enter one or more authorized value codes to a system preference we should offer them a dropdown menu to select from. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31730 [Bug 31730] Link to authorized value interface when an authval is mentioned in preferences -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 30513] New: Add option to update pickup location of pending holds when changing patron home library
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '23

14 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30513 Bug ID: 30513 Summary: Add option to update pickup location of pending holds when changing patron home library Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When changing a patron's home library, it would be helpful if Koha could update the patron's pending holds to be picked up at the new home library. This would be especially helpful for systems where all holds are required to be picked up at the patron's home library, who might want this change to always happen to all holds when a patron is moved. If the update is fully automatic and without exceptions, we could do it on both single and batch patron updates. For libraries that allow more flexibility in hold pickups, it could be helpful to have something more like a modal that lists the patron's holds and asks which should be moved to pickup at the new home library. That'd have to be only for single patron updates. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 34630] New: Update MARC21 cataloging plugin templates with consistent body class
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '23

13 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34630 Bug ID: 34630 Summary: Update MARC21 cataloging plugin templates with consistent body class Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement 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 Blocks: 34566 In preparation for Bug 34566 I'd like to make a global change to the cataloging plugins: Add a "value_builder" class to the <body> tag and remove the inline style, "padding:1em" The inline style creates layout problems when the page has a fixed Bootstrap footer. An update to staff-global.scss will adding padding to the .value_builder class. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34566 [Bug 34566] Update MARC21 cataloging plugins with consistent footers -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 34566] New: Update MARC21 cataloging plugins with consistent footers
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '23

13 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34566 Bug ID: 34566 Summary: Update MARC21 cataloging plugins with consistent footers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 34343 I propose to update these MARC21 cataloging plugin pages to use consistent styling for pop-up window footers: - EXAMPLE.tt (as an example) - marc21_field_006.tt - marc21_field_007.tt - marc21_field_008.tt - marc21_field_008_authorities.tt - marc21_field_008_classifications.tt Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34343 [Bug 34343] Z39.50 search background not updated -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 34661] New: Update UNIMARC cataloging plugins with consistent footers
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '23

13 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34661 Bug ID: 34661 Summary: Update UNIMARC cataloging plugins with consistent footers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement 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: 34566 Like Bug 34566, I propose to update UNIMARC cataloging plugin templates to use consistent styling for pop-up window footers. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34566 [Bug 34566] Update MARC21 cataloging plugins with consistent footers -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 34562] New: Update more pop-up windows with consistent footer markup
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '23

13 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34562 Bug ID: 34562 Summary: Update more pop-up windows with consistent footer markup Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 34343 I would like to change some other pop-up windows to be consistent with Bug 34343 and its children, including: - Add to list (from catalog search results) - SRU Search fields mapping - Bibliographic - SRU Search fields mapping - Authority Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34343 [Bug 34343] Z39.50 search background not updated -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 20453] New: Send notification when hold is cancelled by librarian
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '23

13 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20453 Bug ID: 20453 Summary: Send notification when hold is cancelled by librarian Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When librarian cancel a patrons hold manually, it woul be nice to send a message to a patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 45