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

[Bug 31442] New: Node.js v12 is EOL
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '23

25 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31442 Bug ID: 31442 Summary: Node.js v12 is EOL 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 The currently maintained LTS release is v16. We could start using v18 which will be the new LTS in october and would be current until 2025. https://nodejs.org/en/about/releases/ -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 29489] New: <<branches.branchname>> in RENEWAL notice subject field
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '23

25 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29489 Bug ID: 29489 Summary: <<branches.branchname>> in RENEWAL notice subject field Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: george(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org Using <<branches.branchname>> returns the library name when used in the subject field for a notice template with one apparent exception. If an item is renewed from the OPAC the RENEWAL notice is sent with the subject "<<branches.branchname>>" We are set up so that an item renewal via the OPAC should get recorded statistically as a renewal by the branch the item was checked out at. It would be nice if <<branches.branchname>> filled in the branch name of the library where the item was checked out rather than "branches.branchcode" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 28315] New: PopupMARCFieldDoc is defined twice in addbiblio.tt
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '23

25 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28315 Bug ID: 28315 Summary: PopupMARCFieldDoc is defined twice in addbiblio.tt Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The `PopupMARCFieldDoc` JS function is defined twice in addbiblio.tt.. probably a merge error at some point.. should be easily resolved. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 32232] New: Koha crashes if dateofbirth is 1947-04-27, 1948-04-25, or 1949-04-24
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '23

25 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32232 Bug ID: 32232 Summary: Koha crashes if dateofbirth is 1947-04-27, 1948-04-25, or 1949-04-24 Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I think this only happens if the server/computer is set to an Eastern Canadian timezone. In 1947, 1948 and 1949, Canada decided to switch to daylight saving time at midnight rather than the usual 2am. Therefore, 1947-04-27 00:00:00, 1948-04-25 00:00:00 and 1949-04-24 00:00:00 don't exist in this timezone. Even if borrowers.dateofbirth is set to 'date' (not 'datetime'), Koha crashes, saying the date doesn't exist. I suspect it would happen with any date, but dateofbirth is the most likely (only) field to have dates in those years. To test: 1. Create a patron, setting the date of birth to one of these three dates - 1947-04-27 - 1948-04-25 - 1949-04-24 2. Save the patron --> Error I tested this on production installations in 21.05 and it works fine. Production installations in 22.05, it crashes. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 31604] New: Add the ability to batch add a manual fee to a list of patrons
by bugzilla-daemon＠bugs.koha-community.org 21 Jul '23

21 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31604 Bug ID: 31604 Summary: Add the ability to batch add a manual fee to a list of patrons Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: jheltibridle(a)rcplib.org QA Contact: testopia(a)bugs.koha-community.org It would be very helpful to have the ability to add a manual fee to a list of patrons. An example of using this feature would be to add a collections fee to a list of patrons who are being submitted to a collection agency at the same time. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 31405] New: Set focus for cursor to setSpec input when adding a new OAI set
by bugzilla-daemon＠bugs.koha-community.org 21 Jul '23

21 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31405 Bug ID: 31405 Summary: Set focus for cursor to setSpec input when adding a new OAI set Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When adding a new OAI set from administration, the focus/cursor should be in the first field of the entry form: setSpec -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 26169] New: Run plugins from the CLI / as a script
by bugzilla-daemon＠bugs.koha-community.org 21 Jul '23

21 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26169 Bug ID: 26169 Summary: Run plugins from the CLI / as a script Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org I have some ideas where it could be useful to be able to run a Koha plugin as a script. For example: "echo <oaipmh>records</oaipmh> | koha-plugin --run Koha::Plugin::Dcook::Oaipmh::Harvester --method import kohadev" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 20454] New: Suspend Holds if patron wouldn't be able to check items out
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '23

20 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20454 Bug ID: 20454 Summary: Suspend Holds if patron wouldn't be able to check items out Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisetteslatah(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If a person can't check out an item due to hitting the fine limit, it would be great if the holds could be suspended automatically so it wasn't filled until the account was cleared off. This would be a good system preference so systems that didn't want to use it wouldn't be forced into it. Currently in our system patrons can't check out if they have more than $5 in fines. Sometimes they place a hold, rack up fines, and can't check out the book when it comes in for them. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 30013] New: Limit/throttle SMTP connections
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '23

20 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30013 Bug ID: 30013 Summary: Limit/throttle SMTP connections Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org We have a setup where Koha is sending email through the SMTP server of the library's mother institution. We are seeing a problem with sending lots of emails in one go, where the first emails are sent ok, but then the rest fail with an error like this: unable to establish SMTP connection to (mail.x.y) port 25 It looks like this is due to some limit on the server, making it unresponsive if there are too many connections from the same source in a short time. I don't know a lot about SMTP but I can imagine a couple of solutions: - Introduce a configurable "sleep" period between each call to the external SMTP server (or batches of a configurable number, with a configurable sleep between each batch) - Looking at the response from the server and if "unable to establish SMTP connection" is received, wait for a configurable amount of time before trying to resend the failed message and the rest of the queue -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 25466] New: Review 'problem_reports' column names and types
by bugzilla-daemon＠bugs.koha-community.org 20 Jul '23

20 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25466 Bug ID: 25466 Summary: Review 'problem_reports' column names and types 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org reportid => id borrowernumber => patron_id (created_by_id?) branchcode => library_id problempage => problem_page status => Looks like an ENUM About borrowernumber, I'm not sure it should default to 0, we are leaning to default to NULL. In the code it would probably default to the anonymous patron id? I might be wrong, just putting my notes here for discussion. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6