March 2022 - Koha-bugs - lists.koha-community.org

[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 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

[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

[Bug 24801] New: selenium/administration_tasks.t failing if too many categories displayed
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '23

13 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24801 Bug ID: 24801 Summary: selenium/administration_tasks.t failing if too many categories displayed Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org t/db_dependent/selenium/administration_tasks.t .. 3/3 STRACE: /usr/share/perl5/Try/Tiny.pm:124 in Selenium::Remote::Driver::catch {...} /usr/local/share/perl/5.24.1/Selenium/Remote/Driver.pm:353 in Try::Tiny::try (eval 1543):1 in Selenium::Remote::Driver::__ANON__ (eval 1545):2 in Selenium::Remote::Driver::__ANON__ /usr/local/share/perl/5.24.1/Selenium/Remote/Driver.pm:1330 in Selenium::Remote::Driver::_execute_command /usr/local/share/perl/5.24.1/Selenium/Remote/Driver.pm:1330 in (eval) /kohadevbox/koha/t/lib/Selenium.pm:174 in Selenium::Remote::Driver::find_element /kohadevbox/koha/t/lib/Selenium.pm:166 in t::lib::Selenium::click_when_visible t/db_dependent/selenium/administration_tasks.t:189 in t::lib::Selenium::click SCREENSHOT: https://framapic.org/QV83HpBmIcxN/BAYggoYjgJGi An element could not be located on the page using the given search parameters: //div[@class="main container-fluid"]//a[contains(@href, "/admin/categories.pl?op=delete_confirm&categorycode=PATRON_CAT")],xpath at/kohadevbox/koha/t/lib/Selenium.pm line 174. # Looks like your test exited with 255 just after 3. t/db_dependent/selenium/administration_tasks.t .. Dubious, test returned 255 (wstat 65280, 0xff00) All 3 subtests passed Test Summary Report ------------------- t/db_dependent/selenium/administration_tasks.t (Wstat: 65280 Tests: 3 Failed: 0) Non-zero exit status: 255 Files=1, Tests=3, 61 wallclock secs ( 0.03 usr 0.01 sys + 2.73 cusr 0.29 csys = 3.06 CPU) Result: FAIL -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 19795] New: Allow files to be uploaded and stored in object storage ( Swift and S3)
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '23

13 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19795 Bug ID: 19795 Summary: Allow files to be uploaded and stored in object storage (Swift and S3) 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: chris(a)bigballofwax.co.nz QA Contact: testopia(a)bugs.koha-community.org Currently if we enable uploading and attaching files to a biblio, we only have the option to store the locally on the file system. More and more Koha are being hosted in the "cloud" we should allow people to use the object storage offerings to store their uploaded files. This bug will add support for Openstack Swift, and Amazon S3 only, and only for files attached to biblios. However the code should be able to be used for book covers etc in the future if someone wants to add that feature -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 30363] New: Retrieve uploaded files from staff client by file id or hash
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '23

13 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30363 Bug ID: 30363 Summary: Retrieve uploaded files from staff client by file id or hash Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Some installations have disabled OPAC making opac-retrieve-file.pl inaccessible. It then becomes difficult retrieving public uploaded files in staff client. One may use upload.pl to download by file id, but it requires tools.upload_general_files permission. Add a better mechanism to retrieve files in staff client. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 26053] New: Adding more details to the manual about Patron Restrictions
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '23

13 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26053 Bug ID: 26053 Summary: Adding more details to the manual about Patron Restrictions 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: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com A library can add a manual restriction to a patrons account with a date. This is the date the restriction will be lifted. It would be nice to add to the manual that this is controlled by a cron and would need to be activated for this process to work. --restrictions DAYS purge patrons restrictions expired since more than DAYS days. Defaults to 30 days if no days specified. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 56

[Bug 25770] New: vars loggedinusername and loggedinusernumber should be replaced by use of logged_in_user in templates
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '23

12 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25770 Bug ID: 25770 Summary: vars loggedinusername and loggedinusernumber should be replaced by use of logged_in_user in templates Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Since all templates have the current loggedin user as logged_in_user var (a Koha::Patron object), vars loggedinusername and loggedinusernumber should be replaced in templates. -- You are receiving this mail because: You are watching all bug changes.

1 6