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

[Bug 8483] Borrower reading history should include deleted items
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '23

13 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8483 Michael Adamyk <madamyk(a)ckls.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|madamyk(a)ckls.org | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 35550] New: Merged bibs do not retain lists
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '23

13 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35550 Bug ID: 35550 Summary: Merged bibs do not retain lists Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org When bibs are merged, it appears that if any of them are part of a list, only the destination bib retains a link to a list. All lists linking to the other bibs drop the title. It would be helpful if when a bib is being merged, lists are updated to point to the destination bib record instead of dropping it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 33044] New: BackgroundJob enqueue does not return the job id if rabbit is unreachable
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '23

13 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33044 Bug ID: 33044 Summary: BackgroundJob enqueue does not return the job id if rabbit is unreachable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some sites elect to use the worker without rabbit This largely works, however, when a job is enqueued we don't return the job_id unless our connection was successful - this leads to the enqueued result page not providing a correct link, even though the job will be processed by DB polling To recreate: 1 - In KTD: sudo service rabbitmq-server stop 2 - sudo koha-worker --stop kohadev; sudo koha-worker --queue long_tasks --stop kohadev 3 - In staff client enqueue a batch item modification - note the link to view the enqueued job has no id in the url and takes you to the main background jobs viewer -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 35512] New: Notices transferred during a patron merge should preserve their original dates
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '23

13 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35512 Bug ID: 35512 Summary: Notices transferred during a patron merge should preserve their original dates 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: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When two patrons are merged their notices are transferred over and the 'Updated on' column in the Notice table changes the dates to the date of the merge. While this is expected behavior it would be helpful if the 'Updated on' column kept it's original dates. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

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

13 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12802 --- Comment #119 from mathieu saby <mathsabypro(a)gmail.com> --- Hi Aleisha Could you please update the test plan (new name of the syspref AutoEmailPrimaryAddress)? -- You are receiving this mail because: You are watching all bug changes.

1 0

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

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

12 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 12802] Send notices using several email addresses
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '23

12 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 #154076|0 |1 is obsolete| | --- Comment #118 from Aleisha Amohia <aleisha(a)catalyst.net.nz> --- Created attachment 159780 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=159780&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 AutoEmailPrimaryAddress 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 AutoEmailPrimaryAddress 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 AutoEmailPrimaryAddress 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 AutoEmailPrimaryAddress" 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 AutoEmailPrimaryAddress (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 AutoEmailPrimaryAddress. 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 AutoEmailPrimaryAddress; 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 12802] Send notices using several email addresses
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '23

12 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12802 Aleisha Amohia <aleisha(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0