August 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 37439] New: ChildNeedsGuarantor description misleading
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37439 Bug ID: 37439 Summary: ChildNeedsGuarantor description misleading Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration 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 Unless I misunderstood the purpose of the ChildNeedsGuarantor system preference, I think the description is misleading. It currently states A child patron [doesn't need/must have] a guarantor when adding the patron. However, this is not limited to children. It affect patrons whose patron category is set to 'can be guarantee'. I'm not sure what the best formulation would be. Maybe something like When a patron category is set to 'can be guarantee', the guarantor is [mandatory / not mandatory]. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[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 37427] New: Searching for an empty string for clubs in an item's hold tab is not allowed
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37427 Bug ID: 37427 Summary: Searching for an empty string for clubs in an item's hold tab is not allowed Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: samalau(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To reproduce: 1) have some patron clubs 2) find a bib 3) Click Holds, then Clubs 4) Without entering any text, press the search button 5) Note that the list of clubs is not shown. However, when searching for a patron with an empty string, it returns the entire list of patrons. I think it would be useful if club searching followed this same functionality. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 37360] New: Add 'Protected Status' as one of the things that can be updated via Batch Patron Modification tool
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37360 Bug ID: 37360 Summary: Add 'Protected Status' as one of the things that can be updated via Batch Patron Modification tool Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.auld(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org The new 'Protected Status' characteristic is something that could usefully be included as editable via Batch Patron Modification. Please consider adding. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 53

[Bug 37311] New: Tone down the SMTP servers administration page
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37311 Bug ID: 37311 Summary: Tone down the SMTP servers administration page Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Information about the current configuration is shown as an informational dialog, and default server and debugging status are highlighted in red as if it were an error needing attention. I think the page could be restyled to convey the information without the implicit demand for action. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33

[Bug 37364] New: Improve creation of 773 fields for item bundles regarding MARC21 245 and 264
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37364 Bug ID: 37364 Summary: Improve creation of 773 fields for item bundles regarding MARC21 245 and 264 Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 29560 1) I think we should adjust to also take RDA records using 264 into account here. At least for us these are now the majority of records. + # Publication + if ( $host_field = $marc_host->field('260') ) { + my $s = $host_field->as_string('abc'); + if ($s) { + $sfd{d} = $s; + } + } 773$d is not repeatable, so we should avoid to create 2 entries. Maybe check for existence of 264 first and then fallback to 260 if the first is not found? 260 and 264 are both repeatable. I assume this either uses the first or last entry - can you tell? Ideally it might be good to prefer the entry with first indicator = 3 (current/latest), if it exists: https://www.loc.gov/marc/bibliographic/bd264.html 2) This should take $n$p into account as well, as otherwise a multi-part work will not be distinguishable from the title: + # Title + if ( $host_field = $marc_host->field('245') ) { + my $s = $host_field->as_string('ab'); + if ($s) { + $sfd{t} = $s; + } + } I think this could just be changed to: abnp for the subfield list. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29560 [Bug 29560] Add option to create MARC links when adding items to bundles -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 46

[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