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

[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

[Bug 33268] New: Overlay rules don't work correctly when source is set to *
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33268 Bug ID: 33268 Summary: Overlay rules don't work correctly when source is set to * Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Testing bug 30966 I found a general issue with * rules: My rules: +----+-----+--------+----------+-----+--------+--------+--------+ | id | tag | module | filter | add | append | remove | delete | +----+-----+--------+----------+-----+--------+--------+--------+ | 3 | 245 | source | z3950 | 0 | 0 | 0 | 0 | | 4 | 300 | source | * | 0 | 0 | 0 | 0 | | 5 | 245 | source | batchmod | 0 | 0 | 0 | 0 | +----+-----+--------+----------+-----+--------+--------+--------+ I tested both batch record modification and Z39.50 overlays and found that in both cases: * 245 was protected/unchanged = correct * 300 was unprotected/overwritten = incorrect -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 118

[Bug 26211] New: Patron age checking while doing the membership registration through OPAC
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26211 Bug ID: 26211 Summary: Patron age checking while doing the membership registration through 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: amitddng135(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Currently we are not checking patron age while doing the membership registration from the OPAC. We are checking patron age while doing registration through Staff page. for ex: "The following fields are wrong. Please fix them. Patron's age is incorrect for their category. Ages allowed are 5-17." -- You are receiving this mail because: You are watching all bug changes.

1 32

[Bug 35560] New: Use the REST API for holds history
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '26

26 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35560 Bug ID: 35560 Summary: Use the REST API for holds history 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: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Blocks: 34832 On members/holdshistory.pl Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34832 [Bug 34832] [OMNIBUS] API all the Tables! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 91

[Bug 20965] New: Batch patron anonymization logic is flawed
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '26

26 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20965 Bug ID: 20965 Summary: Batch patron anonymization logic is flawed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org There are two issues here: 1) The tool suggests you can limit by library and checkout date but in fact, the library is not the patrons' library but the library the items were issued at. This is not clear from the UI. 2) When it comes to the actual anonymisation, although we've got a filtered list of Patrons by issues before X and at Library, we then delete ALL issues before X by any of the Patrons selected by the previous query, regardless of which library the checkout took place and thus we ignore the selected Library. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6