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

[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 35533] New: use a specific framework for specific vendor
by bugzilla-daemon＠bugs.koha-community.org 16 Dec '23

16 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35533 Bug ID: 35533 Summary: use a specific framework for specific vendor 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: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Use case : if some vendor sells ebooks and not printed books, a specific framework (different from ACQ) could be used to define relevant values in item fields -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 35585] New: Add item type 942 $c to MarcFieldsToOrder
by bugzilla-daemon＠bugs.koha-community.org 16 Dec '23

16 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35585 Bug ID: 35585 Summary: Add item type 942 $c to MarcFieldsToOrder Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Reading the Koha manual, the only fields available for the MarcFieldsToOrder are: price, quantity, budget_code, discount, sort1, and sort2. However, if a vendor is able to map additional fields, such as item type to the 942 $c, that should be made available. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[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 9567] Favorite reports per user
by bugzilla-daemon＠bugs.koha-community.org 15 Dec '23

15 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9567 Angela Berrett <angela.berrett(a)familysearch.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |angela.berrett@familysearch | |.org -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10295] Add the ability to sort and filter records in staged MARC import batches
by bugzilla-daemon＠bugs.koha-community.org 15 Dec '23

15 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10295 Ray Delahunty <r.delahunty(a)arts.ac.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r.delahunty(a)arts.ac.uk --- Comment #5 from Ray Delahunty <r.delahunty(a)arts.ac.uk> --- And being able to sort largest to smallest batch would help in the Clean and the Delete action now that the page redraws so quickly. Until 22.11 a 'skilled clicker' could toggle a whole page of batches to do a clean-all, and then repeat the toggle action and do a delete-all action. But now the page redraw is so quick we are forced back to page 1 after one click on Clean or on Delete. Keeping the reservoir 'tidy' is now not really feasible by a manual process so we will add the batch deletion to the cleanup_database.pl script. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12802] Send notices using several email addresses
by bugzilla-daemon＠bugs.koha-community.org 15 Dec '23

15 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12802 Aleisha Amohia <aleisha(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #159780|0 |1 is obsolete| | --- Comment #120 from Aleisha Amohia <aleisha(a)catalyst.net.nz> --- Created attachment 159857 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=159857&action=e… Bug 12802: Sent notices using several email addresses Currently it is not possible to select several email addresses to notify a patron. The only place where the mechanism exists is in the overdue_notices.pl script. This patch reuses the EmailFieldPrimary syspref and changes its type to "multiple". Like that it is now possible to select several email addresses. Note that there is no sense to select OFF and another value for this pref. So if the 'OFF' (first valid) value exist, it takes the priority. It will add the ability to choose the email addresses to use to notify patrons. The option is "email", "emailpro" and "B_email". If "OFF" is selected, the first valid address will be returned (same behavior as before this patch). Note for the QA step: I found a possible regression, but IMO it's not a big deal: Before this patch if a letter did not contain a "to_address", the C4::Letters::_send_message_by_email subroutine retrieve the email from the given borrowernumber. This is now done in the EnqueueMessage subroutine. What it means: If a borrower didn't have an email address when the notice was sent to the queue, the email address won't be check again when the notice will really sent to the patron. This change permits to sent a letter to the queue (EnqueueLetter) without any information (from_address, to_address), only the borrowernumber is mandatory to retrieve them. The _send_message_by_email subroutine should not contain any useful code, only sent the letter we ask it to sent. What this patch does: The Koha::Patron::notice_email_address subroutine has been renamed to Koha::Patron::notice_email_addresses (plural). It only gets the patron emails defined in the EmailFieldPrimary pref. If no 'to_address' parameter is given to EnqueueMessage, the emails will be retrieved at this moment. In C4::Message: An old form was found. The EmailFieldPrimary was not check. The smsalertnumber was sent for the to_address param, which is wrong. C4::Reserves: AddReserve and _koha_notify_reserve: The from address is built in the QueueLetter. It is useless to do it here. overdue_notices.pl: The script could be cleaned a little bit if we remove the --email parameter. Indeed it is redundant with this new enhancement. I can propose another patch with a die statement and a message: "you should use the pref EmailFieldPrimary" if the --email is provided. opac/opac-shareshelf.pl and opac/opac-memberentry.pl: just remove the from and to address. They will be filled on sending to the queue (because of the borrowernumber). Test plan: 1. Apply this patch without updating the pref EmailFieldPrimary (or fill it with a single value if it is not done yet). 2. Try the different way to sent notices to a patron (check the following letter code: HOLD, CHECKIN, CHECKOUT, PREDUE, RENEW, DUE). 3. Verify the email is correctly sent to the message_queue. 4. Fill the pref with email and emailpro (for instance) 5. Verify that 2 notices are sent to the message_queue: 1 with the email and 1 with the emailpro. 6. You can also verify that only 1 notice is generated if the emailpro is empty. Important note for testers: Pending messages must be removed each time you change the value of EmailFieldPrimary. When there are already existing pending messages for a borrower, Koha tries to update them rather than enqueuing new ones, but it will not update the recipient's email address, nor add/remove messages depending on the new value of EmailFieldPrimary; not sure if this is a bug or not. Signed-off-by: Mathieu Saby <mathsabypro(a)gmail.com> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 35577] New: Self-registration creates empty patron attributes
by bugzilla-daemon＠bugs.koha-community.org 15 Dec '23

15 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35577 Bug ID: 35577 Summary: Self-registration creates empty patron attributes 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: david.roberts(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When creating a new users using the self-registration feature, all extended patron attributes are created as empty lines in the database even if they are not completed in the form: select * from borrower_attributes where borrowernumber = 265932; +--------+----------------+-----------+-----------+ | id | borrowernumber | code | attribute | +--------+----------------+-----------+-----------+ | 408566 | 265932 | JOBROLE | Test | | 408567 | 265932 | ESRCAT | | | 408568 | 265932 | NOTIF | | | 408569 | 265932 | CONTRACT | | | 408570 | 265932 | STUDY | | | 408571 | 265932 | CONT_TYPE | | | 408572 | 265932 | TRUST_OTH | | | 408573 | 265932 | TRUST | | +--------+----------------+-----------+----- Editing this user record in the staff client then deletes the empty attributes: select * from borrower_attributes where borrowernumber = 265932; +--------+----------------+-----------+-----------+ | id | borrowernumber | code | attribute | +--------+----------------+-----------+-----------+ | 408574 | 265932 | CONT_TYPE | TEMP | | 408575 | 265932 | JOBROLE | Test | +--------+----------------+-----------+-----------+ -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[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