May 2024 - Koha-bugs - lists.koha-community.org

[Bug 35885] New: ERM vendor sort order
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35885 Bug ID: 35885 Summary: ERM vendor sort order Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: Laura.escamilla(a)bywatersolutions.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Currently the vendor drop-down list shows the vendors in the order that they were added to the Acquisitions module. It would be ideal if the vendors were sorted in alphabetical order so that libraries could easily locate their selection. -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 33224] New: OPACHoldsIfAvailableAtPickup and no on-shelf holds don't mix well
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33224 Bug ID: 33224 Summary: OPACHoldsIfAvailableAtPickup and no on-shelf holds don't mix well 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This is the situation: The library wants to prevent on-shelf holds as much as possible, only allowing for transfers if the copy at the patron's library is not available. For example, a record with a checked out copy at Centerville and an available copy at Midway. A Centerville patron should be able to place a hold for pickup at Centerville (the hold will appear on Midway's holds to pull for transfer to Centerville). A Midway patron should not be able to place a hold for pickup at Midway since the Midway copy is available. Does that make sense? This is the setting: - circulation rules allow on-shelf holds only if any unavailable - OPACHoldsIfAvailableAtPickup is set to Don't allow Currently, this allows the Midway patron to place a hold for pickup at Midway. To test: 1. Set up the circulation rule so that on-shelf holds are allowed ('Yes') 2. Create a record with two items, one at Centerville and one at Midway 3. Check out the Centerville item 4. Log into the OPAC with a Midway patron (I used Henry Acevedo) 5. Try to place a hold on the record --> Midway is not a valid pickup location (correct behaviour) 6. Cancel 7. Change the circulation rules so that on-shelf holds are only allowed 'if any unavailable' 8. Try to place a hold on the record from the OPAC again --> The system allows you to place the hold for pickup at Midway (incorrect behaviour) 9. Optionally, check the Holds to pull for Midway (the hold is there, it shouldn't) 10. Optionnaly, check in the Midway item (it is trapped for Henry's hold) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 33284] New: checkout_renewals table retains checkout history in violation of patron privacy
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33284 Bug ID: 33284 Summary: checkout_renewals table retains checkout history in violation of patron privacy Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 30275 The checkout_renewals table introduced in bug 30275 can retain a link between a patron and an issue_id when the patron's privacy is set to Never. That data should be anonymized. To recreate: - have a patron with their privacy set to Never retain reading history - check an item out to the patron, renew it via the OPAC - confirm your patron's borrowernumber can be found in checkout_renewals.renewer_id and the issue_id for your checkout can be found in checkout_renewals.checkout_id - check your item in - confirm your patron's borrowernumber has been removed from old_issues.borrowernumber - confirm your patron's borrowernumber and the issue_id for your checkout can still be found in checkout_renewals.checkout_id (along with a note that the renewal happened via the OPAC, thereby making it perfectly clear that this was a patron renewing the item they had checked out themselves). Should we not replace checkout_renewals.renewer_id with the anonymous patron's borrowernumber when the item is returned, if the patron is set to not retain reading history? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30275 [Bug 30275] Checkout renewals should be stored in their own table -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 56

[Bug 31167] New: Only mark due dates in the past red on overdues report
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31167 Bug ID: 31167 Summary: Only mark due dates in the past red on overdues report Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 27996 Bug 27996 added formatting to the due dates on the overdues report, but we forgt that it doesn't only show due dates in the past. If you check the checkbox on top, also current checkouts with due dates in the future will display. They area also formatted in red now. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27996 [Bug 27996] Format of "Due date" on Circulation > Overdues page -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 31019] New: UNIMARC field help link when cataloguing - default location needs updating
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31019 Bug ID: 31019 Summary: UNIMARC field help link when cataloguing - default location needs updating 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: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When cataloguing on a UNIMARC installation, clicking on the ? for field help now goes to https://www.ifla.org/, for example for 500: https://www.ifla.org/#500. This looks like a redirect from https://archive.ifla.org/#500 (the MarcFieldDocURL system preference indicates that http://archive.ifla.org is used if nothing is entered in the system preference). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 22458] New: PatronSelfRegistrationEmailMustBeUnique disallows self modification requests if multiple accounts share an email address
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22458 Bug ID: 22458 Summary: PatronSelfRegistrationEmailMustBeUnique disallows self modification requests if multiple accounts share an email address 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: jrobb(a)sekls.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- PatronSelfRegistrationEmailMustBeUnique causes unexpected behavior on the patron self modification screen ("your personal details") in the OPAC. When enabled, the system preference blocks existing accounts from submitting account modification requests if the primary email associated with the account is also associated with another account in the database. This means if a parent account and a child account both use the same email address, neither can submit account modification requests via the OPAC. This system preference should only affect new self registered accounts. To reproduce this behavior: 1. Set PatronSelfRegistrationEmailMustBeUnique to 'Consider' 2. Create two different accounts with the same primary email address 3. Log into the OPAC with either account 4. Visit "your personal details" 5. Make a change unrelated to email address and submit 6. The submission is blocked with a message about duplicate email addresses -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 31124] New: koha-remove fails to remove long_tasks queue daemon, so koha-create for same <instance> user fails
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31124 Bug ID: 31124 Summary: koha-remove fails to remove long_tasks queue daemon, so koha-create for same <instance> user fails Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: rel_22_05_candidate Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: matted-34813(a)mypacks.net QA Contact: testopia(a)bugs.koha-community.org >From the command line as a koha shell user: 1) koha-remove <instance> fails to remove the backgroundjobs / long_tasks(queue) daemon. (ps -aef | grep long_tasks) So when it tries to "deluser" the <instance>-koha user from /etc/passwd that errors because a process is still running for that user's PID. 2) koha-create <instance> fails for that same instance name from that point onward. 3) koha-worker --help doesn't show any --queue option Cursory investigation shows: --queue support was added in version 22.05 to koha-worker. koha-worker --stop --queue long-tasks <instancename> works to shut down that specified queue. --status and --start are also supported. Suggested Fix: 1) koha-remove needs to have an entry added: koha-worker --stop --queue long_tasks <instancename> added accordingly to get that process to stop so the latter deluser will succeed. 2) koha-worker needs: the --queue option should be added to the --help / POD Also, koha-worker --help should at least show: Usage: koha-worker [--start|--stop|--restart] [--quiet|-q] [--queue <queuename>] instancename1 [instancename2...] and also: --queue <queuename> Specify a queue name One should be able to be able(test plan): test 1) koha-remove kohadev koha-create --create-db kohadev koha-remove kohadev without problems in the ktd or other test environment to be fixed. test 2) Also, koha-worker --help should at least show: Usage: koha-worker [--start|--stop|--restart] [--quiet|-q] [--queue <queuename>] instancename1 [instancename2...] and also: --queue <queuename> Specify a queue name -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 17338] New: waitingreserves.pl should keep you on the same tab when cancelling a hold
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17338 Bug ID: 17338 Summary: waitingreserves.pl should keep you on the same tab when cancelling a hold 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When you cancel a hold on the Hold(s) over tab, and the process is done, it puts you back on the Hold(s) waiting tab. It should keep you on the same tab. It would also be nice if the search box is used that it would keep the focus. We use the following jQuery to help streamline the cancelling process: //Default Holds awaiting pickup to Holds over tab $("#holdso form[action='waitingreserves.pl']").attr("action","waitingreserves.pl#holdsover"); if (window.location.href.indexOf("cgi-bin/koha/circ/waitingreserves.pl#holdsover") > -1) { $("form[action='waitingreserves.pl']").attr("action","waitingreserves.pl#holdsover"); } setTimeout(function() { $("#holdso_filter input").focus(); },10); //End default tab -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 36229] New: koha-run-backups should be first daily job
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36229 Bug ID: 36229 Summary: koha-run-backups should be first daily job 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org There's a couple of reasons why koha-run-backups should be the first job in /etc/cron.daily/koha-common. 1. It takes a backup before running scripts that change database contents. If there is a problem with those scripts, you'll have a very recent backup on which to fallback. 2. It's a resource intensive job. If you have a lot of Koha instances, this means you're running your most intensive job at the end of the job run, which might be a lot later in the day than you anticipate. (Of course, you can update /etc/crontab to change when /etc/cron.daily is run, but this will help reduce impact in the meantime.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 36163] New: Usage statistics - Not possible to select a country
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36163 Bug ID: 36163 Summary: Usage statistics - Not possible to select a country Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha.gehim(a)erine.email QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Site: .../cgi-bin/koha/admin/usage_statistics.pl If you try to select a country, you get an error: == The value of your system preference 'UsageStatsCountry' is not valid (Germany). Please select a valid one. == It doesn't matter which country you chose, no country is valid. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26