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

[Bug 42259] New: Accessing deleted ILL is 500 error & not 404
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '26

06 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42259 Bug ID: 42259 Summary: Accessing deleted ILL is 500 error & not 404 Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com I noticed this because I saw a "request to delete ILL request" email and clicked the link to view the request, but another staff member had already deleted it. You receive a 500 server error due to a missing template: Template process failed: file error - : not found at /kohadevbox/koha/C4/Templates.pm line 146 in C4::Templates::output at /kohadevbox/koha/C4/Templates.pm line 146 in C4::Output::output_and_exit at /kohadevbox/koha/C4/Output.pm line 384 in (eval) at /kohadevbox/koha/ill/ill-requests.pl line 127 ... This is the `output_and_exit()` call passing an 'unknown_ill_request' error after checking that the request doesn't exist. I see a `[% CASE 'unknown_ill_request' %]` line in koha-tmpl/intranet-tmpl/prog/en/includes/blocking_errors.inc so it seems like Koha should be set up to handle this error gracefully. Perhaps an issue with the ill-requests.tt template. Ideally, the response would both say "ILL request not found" and be a 404. I looked at how other templates handle this but couldn't quite figure it out. I see that some missing objects (biblio, patron) return HTTP 200 which seems semantically incorrect. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 41200] New: Refocus certain elements on hide or remove
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '26

06 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41200 Bug ID: 41200 Summary: Refocus certain elements on hide or remove Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: jake.deery(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, oleonard(a)myacpl.org On the OPAC, there are a few instances of the browser's focus caret disappearing when an element is removed. This causes problems for people with screen readers, as their reader doesn't know what element should come next in the page's flow any more. I shall propose a set of patches to resolve this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 39328] New: Buttons should maintain focus after toggling
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '26

06 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39328 Bug ID: 39328 Summary: Buttons should maintain focus after toggling Change sponsored?: --- Product: Koha Version: unspecified Hardware: Macintosh OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: jake.deery(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, oleonard(a)myacpl.org A customer's accessibility report has highlighted to us a malfunction on some of our button focus behaviours. To paraphrase the auditor: "When it is activated on highlight / unhighlight, the focus moves to a random location on the page, such as to the "1" pagination button. That is, as opposed to staying on the activated link. Witnessed on iOS. Also witnessed on OPAC details, via iOS, with the "Add to cart" link. When activated, the focus moves to a random location on the page, such as to the decorative folder icon preceding the link's label. That is, as opposed to staying on the activated link, which now has an updated label of "In your cart". Again on iOS, with the "highlight/unhighlight" links on OPAC details. When activated, the focus moves to a random location on the page, such as to the "Print" link. That is, as opposed to staying on the activated button. Additionally, with the sortable header column buttons, on search history, on iOS. When activated, the focus moves to a random location on the page, such as to the "Enter search here" input field. That is, as opposed to staying on the activated button. Lastly, on iOS, on the OPAC details page, with the "+/-" buttons in the holdings table. When activated, the focus moves to a random location on the page, such as to the first table header. That is, as opposed to staying on the activated button." I'm not sure how much of these issues can be attributed to us, versus iOS/Safari just being... iOS/Safari. I thought I would log here, anyway. :-) Jake. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 42268] New: Add ability to update preferred name conditionally.
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '26

06 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42268 Bug ID: 42268 Summary: Add ability to update preferred name conditionally. Initiative type: --- Sponsorship --- status: 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: alyssa.drake(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Currently, when a patron is created, if the first name field is filled in and the preferred name is left blank, the preferred name field populates with the first name. Let's say the library makes a change to the first name field. If the preferred name field is filled in, changing the first name will not change the preferred name. Normally, this is ideal. You wouldn't want the preferred name field to update every time the first name field is altered BUT in some cases libraries want to make changes to the first name field AND have that change also update the preferred name field IF the preferred name field has never been manually updated/if it has only ever been automatically populated because it was left blank. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 23350] New: Add another variable for advanced prediction pattern
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '26

06 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23350 Bug ID: 23350 Summary: Add another variable for advanced prediction pattern Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: marjorie.barry-vila(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Hi, Currently, in the prediction pattern we can only set 3 variables (X, Y, Z). For long numbering such as "Vol., Number, Season, Year" a 4th variable would be useful. Regards, Marjorie -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 42256] New: Ungrouping holds can leave patron with more holds than they should have
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '26

06 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42256 Bug ID: 42256 Summary: Ungrouping holds can leave patron with more holds than they should have Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Depends on: 15516 See Bug 42255 for details of how Koha is sometimes considering grouped holds for hold limits and sometimes not. To recreate this issue: 1 - set a circ rule with: -- Holds allowed (total): Unlimited -- Holds allowed (daily): Unlimited -- Holds per record (count): 2 2 - Place 2 holds on the same record for the same patron 3 - Try to place a 3rd hold, get an error "too many holds" 4 - group your 2 existing holds 5 - try to place a 3rd hold; it works! 6 - ungroup your 2 original holds 7 - your patron now has 3 ungrouped holds on the same record where they should only be allowed 2 Currently holds can only be un-grouped by staff, which lessens the likelihood of a patron abusing this loophole. But the loophole is still not ideal, and will become more troublesome if Bug 42255 makes the total holds count consider groups. We could block ungrouping holds if doing so would push the patron over the holds limit? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 [Bug 15516] Allow to place a hold on first available item from a group of titles -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 41136] New: Advanced doesn't search on SRU servers
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '26

06 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41136 Bug ID: 41136 Summary: Advanced doesn't search on SRU servers Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The advanced editor has a hardcoded use of 'zed' for the type of server, which implies Z39.50 and not SRU. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 Sara Brown <sbrown(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42264 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42264] New: Ungrouping holds or grouping existing holds requires top-line reserveforothers permission
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42264 Bug ID: 42264 Summary: Ungrouping holds or grouping existing holds requires top-line reserveforothers permission Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com While staff with the place_holds permission (and no other permissions from reserveforothers) *can* create a hold group by selecting multiple bibs in search results and choosing the 'Treat as hold group' option on the 'Place holds' screen, they cannot create a hold group from existing 'standard' holds or ungroup a hold group. Grouping existing holds and ungrouping holds requires the top-line reserveforothers permission, but it should either be part of place_holds or be a separate permission so that staff needn't also have alter_hold_targets and modify_holds_priority in order to use hold groups. To replicate the error with creation: -Use a staff patron account with only the place_holds permission from the reserveforothers group -Create 2 or more standard holds for another patron -In the regular patron's account, select the standard holds and click 'Group holds' -On the modal, click 'Group' -Note the error message: "Authorization failure. Missing required permission(s)." To replicate the problem with ungrouping: -Find/create a patron with a group hold using a staff account with top-line reserveforothers permission -Sign in using a staff patron account with only the place_holds permission from reserveforothers -Go to the regular patron account where the group hold was placed -Click the number in the 'Hold group' column, then select 'Ungroup holds' from the modal -Note that the modal disappears with no error message, but the hold has not been ungrouped -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42261] New: Inaccurate detection of character-length errors in fixed marc fields 006/007
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '26

03 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42261 Bug ID: 42261 Summary: Inaccurate detection of character-length errors in fixed marc fields 006/007 Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: yannis.kwon(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This bug resulted from Bug 40272 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40272) where Koha now shows an error for invalid character lengths in fixed-length control fields, but they are not being detected incorrectly and showing errors where there are none. While there are 17 spaces for 006, Koha is requiring 18 characters and is not recognizing the usual placeholders | and #. This error was noticed only with electronic materials computer files so far where characters 2-17 are supposed to be undefined. A bit more testing for 007 is needed. General behavior/recreation: - When editing a marc record for a DVD, blu-ray, or other forms of computer discs or electronic materials, there will be a warning that pops that says "The following fixed-length control field(s) have an invalid length: 006,007. Please fix." - In 006, coding with anything less than 18 characters will trigger the error, when 006 only has 17 positions - Also in 006, trying to fill those 18 required positions with placeholders | # will not be recognized -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2