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

[Bug 29239] New: [OMNIBUS] Replace jQueryUI's timepicker with flatpickr
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '23

02 Feb '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29239 Bug ID: 29239 Summary: [OMNIBUS] Replace jQueryUI's timepicker with flatpickr 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: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com https://flatpickr.js.org/ Decided on bug 28376. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 42

[Bug 32784] New: Reoccurring News
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '23

02 Feb '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32784 Bug ID: 32784 Summary: Reoccurring News 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It would be helpful if we could make certain news articles reoccurring. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 30345] New: Koha::BackgroundJob->enqueue should set borrowernumber=undef if no userenv
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '23

02 Feb '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30345 Bug ID: 30345 Summary: Koha::BackgroundJob->enqueue should set borrowernumber=undef if no userenv Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It currently explodes. This is annoying in the tests. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 31351] New: Worker dies on reindex job when operator last name/first name/branch name contains non-ASCII chars
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '23

02 Feb '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31351 Bug ID: 31351 Summary: Worker dies on reindex job when operator last name/first name/branch name contains non-ASCII chars Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: major Priority: P5 - low Component: Searching Assignee: stalkernoid(a)gmail.com Reporter: stalkernoid(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: nugged(a)gmail.com "malformed UTF-8 character in JSON string, at character offset 38 (before "\x{fffd}"register_id...") at /home/vagrant/kohaclone/Koha/BackgroundJob.pm line 170." Steps to reproduce: 1. Go to your user settings and change your current logged user's name/surname so it contains non-ASCII characters, for example, "ä" (U+00E4). 2. Log out and log back in with the same user so the session will be refreshed with updated info. 3. Open any biblio record in marc-record edit mode and save it back: just to initiate ElasticSearch background reindex job creation. 4. Open background jobs admin page, and you will see there "Update Elasticsearch index" job that is in the status "New". Normal behaviour for it is to already get to "Finished" status, as this job is simple and going to be completed quickly, but it's going to remain in "New" status and never get to the "Finished" state. That's why: 5. Stop Koha-worker from the root user: `koha-worker --stop %YOUR_KOHA_INSTANCE%` (%YOUR_KOHA_INSTANCE% is your Koha instance name, for ex. 'kohadev'), and stop RabbitMQ service inside the machine from root: `service rabbitmq-server stop`, then if you run misc/background_jobs_worker.pl inside of your koha machine from under koha user, that script won't be able to connect to RabbitMQ (it warns about this) so it will process tasks one-by-one itself in "no-server-available" mode, and thus you will be able to find the problem, why background job task remains "New": you will see the "malformed UTF-8 character in JSON string" error. 6. Apply the patch. 7. Run background_jobs_worker.pl script again, ensure that after it warns about "Connection refused" to RabbitMQ server, it processes all "New" tasks again like in step 5, but the "malformed UTF-8 character in JSON string" error is gone and if you check background jobs admin page, the status of that same job is now "Finished". This means since now the bug is solved, so: 8. Start RabbitMQ service inside the machine from root: `service rabbitmq-server start`. Start Koha-worker from the root user: `koha-worker --start %YOUR_KOHA_INSTANCE%`. 8. Repeat from step 3: edit biblio and save the record again, to create another background job. 9. Check the background job page and see that the new job now has "Finished" status, so the patch works. -- You are receiving this mail because: You are watching all bug changes.

1 62

[Bug 30360] New: Add helper methods to Koha::BackgroundJobs
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '23

02 Feb '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30360 Bug ID: 30360 Summary: Add helper methods to Koha::BackgroundJobs Change sponsored?: --- Product: Koha Version: unspecified 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It would be handy to have background jobs just call a simple method for: * Setting the job as started * Updating the progress * Setting as finished -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 31223] New: Batch edit items - not working anymore in 22.05
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '23

02 Feb '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31223 Bug ID: 31223 Summary: Batch edit items - not working anymore in 22.05 Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: isabel.pineda(a)ds.edu.sv QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In a register with several items I select all (or some) items and click "edit selected items". I make the modification (write a public note, change the signature, change item type etc.) and click "Save", the modifications don't get saved. It used to work in previous versions. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 48

[Bug 32796] New: Marc modification template copying multiple subfields issue
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '23

02 Feb '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32796 Bug ID: 32796 Summary: Marc modification template copying multiple subfields issue Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: bernard.scaife(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org 1. Marc record contains a 264 field with multiple subfield $a. eg =264 \1$aAbingdon, Oxon ;$aNew York, NY :$bRoutledge,$c2020. 2. Marc modification template created to set to "Copy All" 264a to 260a 3. Stage record with template from #2 4. Note that 2 x 260 fields created =260 \1$aAbingdon, Oxon =260 \1$aNew York, NY 5. Expected outcome: =260 \1$aAbingdon, Oxon;$aNew York, NY Variation using "Copy 1st" doesn't work either. Result is =260 \1$aAbingdon, Oxon -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 25508] New: Confusing renewal message when paying accruing fine
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '23

02 Feb '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25508 Bug ID: 25508 Summary: Confusing renewal message when paying accruing fine Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1 - Make sure FinesMode is on, RenewAccruingItemWhenPaid is off 2 - Checkout an item to a patron and make it overdue (can backdate the checkout) 3 - Make sure the itemtype has fines that will be charged 4 - Charge the fines: Set finesMode = production perl misc/cronjobs/fines.pl -v 5 - Check the fine appears on the patrons account 6 - Pay off the fine 7 - Receive alert after payment that reads: "The fines on the following items were paid off, renewal results are displayed below: No title ( ): Not renewed - Unknown error" Looks like we're not properly hiding that alert when RenewAccruingItemWhenPaid is off? So it's reporting that nothing was renewed? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 46

[Bug 23380] New: GuessAuthTypeCode should check authority type exists
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '23

02 Feb '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23380 Bug ID: 23380 Summary: GuessAuthTypeCode should check authority type exists Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The method GuessAuthTypeCode is used when importing from batch or z3950/SRU to find the local authority type depending on MARC flavour and authority record fields. This method should check that found type is configured. Otherwise it can generate software errors when type code is used to fetch Koha::Authority::Type. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 20632] New: Staff users without superlibrarian can't log into OPAC
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '23

02 Feb '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20632 Bug ID: 20632 Summary: Staff users without superlibrarian can't log into OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Ok, I hope it's not me, but in case it isn't, this is a bad bug: - Create or change your staff user to have all available permissions BUT superlibrarian - Log out - Log into staff - it works. Log out. - Log into OPAC - it won't work. Not good at all. This is bad for at least 2 reasons: - Often staff accounts are used like normal patron accounts by staff. - Because of permissions, sometimes the OPAC is the only place a staff user can change their password. Tested on master after a reset_all. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15