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

[Bug 39420] New: Item edit breadcrumbs wrong
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39420 Bug ID: 39420 Summary: Item edit breadcrumbs wrong Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org When you open a record detail view, this is the breadcrumb: ``` Home / Catalog / The title / Details ``` If you choose to edit its items, the breadcrumb becomes: ``` Home / Cataloging / Edit The title (Record # NN) / Items ``` So you cannot actually use the breadcrumb to go back to the detail page for the record, but instead you go to the MARC editor. I believe it should be like this instead: ``` Home / Catalog / The title / Edit items ``` If we wanted to have a shortcut for editing the MARC record, I would add a link in the breadcrumb like this: ``` Home / Catalog / The title ([edit](/the/url))/ Edit items ``` But, right now, it is super weird. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 43355] New: Add a /search API endpoint for biblios
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43355 Bug ID: 43355 Summary: Add a /search API endpoint for biblios Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: caroline.cyr-la-rose(a)inlibro.com, dcook(a)prosentient.com.au, hammat.wele(a)inlibro.com, jonathan.druart(a)gmail.com, kyle(a)bywatersolutions.com, m.de.rooy(a)rijksmuseum.nl, magnus(a)libriotech.no, mathsabypro(a)gmail.com, paul.derscheid(a)lmscloud.de, philippe.blouin(a)inlibro.com, tomascohen(a)gmail.com Depends on: 25870, 32734 Blocks: 27113, 27428 Target Milestone: --- +++ This bug was initially created as a clone of Bug #25870 +++ To try and get that bug moving again I thought I'd work from a blue sky proposal taking comments from the original bug into consideration and adding a dedicated /search endpoint. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 [Bug 25870] Add a q_ccl query parameter to /biblios (ie add search API endpoint) https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27113 [Bug 27113] Elasticsearch: Autocomplete in search https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27428 [Bug 27428] Show the number of records in the bibliographic record detail page with Elasticsearch https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32734 [Bug 32734] Add GET endpoint for listing Biblios -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 39

[Bug 43151] New: ES should apply search filters on each item discretely
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43151 Bug ID: 43151 Summary: ES should apply search filters on each item discretely Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 42835 Target Milestone: 26.11 When filtering search results using item record values, Koha checks for each of those values at the biblio level, rather than at the item level. This leads to undesirable search results. For example, assume you have a biblio with two items: - item 1 is itype BOOK and collection FICTION - item 2 is itype AUDIO and collection NONFICTION Currently, if a user performs a search limited to itype=BOOK and collection=NONFICTION, this biblio will be returned because it has at least one BOOK item and at least one NONFICTION item. But the user expectation is that the search will return biblios where at least one item that is both a BOOK and NONFICTION. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42835 [Bug 42835] ElasticSearch should have an items index -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 43432] New: ReportsExportLimit system preference - clarify description
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43432 Bug ID: 43432 Summary: ReportsExportLimit system preference - clarify description Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Target Milestone: --- The current description for this system preference uses "records". It actually controls the number of rows downloaded, which may or may not be records. Current description: Download a maximum of _____ records when downloading from the reports module. NOTE: Only a positive value will enforce a limit. A specific limit in the report overrides this setting. The system preference description should be updated to reflect this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 43346] New: MarkLostItemsAsReturned does not work without userenv set
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43346 Bug ID: 43346 Summary: MarkLostItemsAsReturned does not work without userenv set Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- If MarkLostItemsAsReturned is called when there is no userenv set it fails because "checkin_library" is set from userenv. $issue->checkin_library( C4::Context->userenv->{'branch'} ); I have developed an Opac payment plugin with a callback to a public REST endpoint, that is authenticated by a cryptographic token (similar to the easy payments plugin). This callback is executed without userenv and will therefore occasionally fail. As the item is lost, it is unclear what the checkin_library should signify. Setting it the the branchcode on the issue seems just as appropriate. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 43225] New: Renewal confirmation message formatting is missing punctuation and space
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43225 Bug ID: 43225 Summary: Renewal confirmation message formatting is missing punctuation and space Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation 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, kyle(a)bywatersolutions.com Target Milestone: --- The new renewal confirmation message introduced by Bug 23415 is missing a period and space between the amount due and the second sentence. It currently reads: "The patron has a debt of [amount]Are you sure you want to renew checkout(s)?" It should be, with the period and then space after the amount due: "The patron has a debt of [amount]. Are you sure you want to renew checkout(s)?" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 38638] New: Offer the option to set non-priority option when placing multiple holds
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38638 Bug ID: 38638 Summary: Offer the option to set non-priority option when placing multiple holds Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 22789 When placing multiple holds in the staff interface there isn't an option to set the holds as non-priority. As far as I know there's not a technical reason not to include the option? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22789 [Bug 22789] Establish non-priority holds -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 --- Comment #955 from Chloé Zermatten <chloe.zermatten(a)openfifth.co.uk> --- (In reply to Jonathan Druart from comment #953) > Very quick, and late, QA review: > > 1. admin/circulation_triggers.tt > 34 const letters = [% To.json(letters) | $raw %]; > > => XSS? > > 2. admin/circulation_triggers.tt > 37 const logged_in_library_id = "[% > Branches.GetLoggedInBranchcode | html %]"; > We have a global logged_in_user JS variable already > > 3. Koha/REST/V1/CirculationRules.pm > 120 return $c->render_invalid_parameter_value( > 121 { > 122 path => '/query/rules', > 123 values => { > 124 uri => '/api/v1/kinds', > 125 field => 'rule_name' > 126 } > 127 } > 128 ) unless $valid_kinds->{$rule_key}; > > Is this correct? /kinds is not defined in the api specs. Should it be > /circulation_rules/kinds? > > 4. Certainly a personal pov but the code in Koha/REST/V1/CirculationRules.pm > starting at l.244 (`my $logged_in_user = $c->stash('koha.user');`) to return > the 403 is confusing. > Too many return statements maybe? > I am also not sure it's covered properly by tests (but I may have missed > them). > > 5. Why do we still have occurrences of "edit_notice_status_triggers" in > t/Koha/Auth/Permissions.t? > > t/Koha/Auth/Permissions.t:# Remove the deprecated > edit_notice_status_triggers permission (bug 10190). > t/Koha/Auth/Permissions.t:C4::Context->dbh->do(q|DELETE FROM permissions > WHERE code = 'edit_notice_status_triggers'|); > > 6. i18n > a. CirculationTriggersFormConfirmTriggerDelete.vue > Untranslatable strings? > + :formTitle=" > + initialized > + ? `Confirm deletion of Trigger ${triggerNumber} for > ${handleContext(library_id, libraries, 'library_id')}` > + : 'Confirm circulation trigger deletion' > + " > b. EditActions.vue > + {{ $__("Add new trigger") + " " + triggerNumber }} > + {{ $__("Edit trigger") }} {{ " " + triggerNumber }} > => Should use `$__x()` to correctly handle this translation. > Same pattern exist in other files. > > 7. EditActions.vue use an svg icon, any good reason or that? Doesn't it > exist in font-awesome? > > 8. Duplicated CSS rules > a. Just one example, but there are many like that: > EditActions.vue > CirculationTriggersFormConfirmTriggerDelete.vue > CirculationTriggersFormConfirmReset.vue > All 3 have the same CSS rules for `.chevron-buttons`, and only > EditActions.vue have the .chevron-buttons element in the template. > b. v-select related rules already exist in the shared css/vue.css (see "Bug > 38201: Do not duplicated CSS rules") > > 9. In (at least) EditNotice.vue, there are !== conditions that can certainly > be simplified: > `v-if !== '' && !== null && !== undefined` => simply "v-if"? or do we care > about 0? > If we care about 0, then `!== null, !== undefined` and `!= null` are > equivalent. > > 10. I don't understand why all the functions are in the stores file, is this > a vue best practice? Many thanks for this! Went through the list, and made changes accordingly. Here is where I landed: 1: Agreed, fixed 2: logged_in_user is not available to circulation triggers as it stands. I could make it available, but it also is a lot more data than what circulation triggers really needs. That said we do need to move from consulting the logged in library to looking for the logged in user’s home library instead - and that much is fixed (see commit message). 3: Agreed, fixed 4: I think we could extract code and collapse guard clauses 2 and 3 - but reckon that's a later follow-up? Re-tests - I’m not seeing any that check the permissions logics and 403s either (part of this is on me, I spotted the missing clause, added it, and forgot to update the tests accordingly, my bad!) -> added them. 5: The comment between those two lines reads “It may still be present in DBs that pre-date the atomic update.” I don’t know if you’ve seen it (won’t come up if grepping I don't think?). Does that answer it? I can ask Martin about it otherwise. 6-8: Agreed, fixed. 9: left untouched for now. “” is ‘No letters' where admins explicitly want nothing sent for this context, while null / undefined indicates no override, fall back to the less specific rule set. Where ‘No letters’ is set, we don’t display the transport type options - hence the explicit '' check. I think some cases can definitely be simplified in a follow up (which can be included as preparation for bug 39756. I do remember running into issues much earlier on when I did try to simplify - I don’t mind having another go, but I do think it’d be better in a follow-up. 10: best practice: I don’t think so - but I do think it’s a step in that direction (the direction of travel so far had been to remove duplicate code, prevent redundant data (re)loads, remove duplicated logic, etc). Further refactoring into more specialised components will be beneficial. 39756 (long overdue cron) can certainly take that refactoring further. Thoughts? I’ll happily stand corrected on anything I got wrong! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10190] Overdue notice triggers based on item type
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10190 --- Comment #954 from Chloé Zermatten <chloe.zermatten(a)openfifth.co.uk> --- Created attachment 205599 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=205599&action=e… Bug 10190: (QA follow-up): fixes phase five 1. apply html filter to letters so notice names are escaped (must be done in attribute so the JSON format of the letters can be parsed). 2. fix a correctness issue where the frontend was pinning the logged in library instead of the logged in user's home library, which would have led to 403s (correct) when saving rules. Since the library dropdown is deliberately disabled unless a user has the manage_circ_rules_from_any_libraries permission, the user would then have needed to use 'Set library' to match their home library to fix this. Prevent the issue by setting the library to the user's home library. Also rename the variable to user_library_id. 3. list_rules correctly references /api/v1/circulation_rules/kinds 4. make untranslatable strings translatable 5. swap svg for font-awesome icon. 6. avoid css duplication: - remove dead / unused scoped css (leftover from an early component extraction) - import vue.css and only leave the minimal override required. 7. improve set_rules test coverage: add tests for manage_circ_rules / manage_circ_triggers separation Test plan: 1) Administration > Circulation triggers: notice the 'Letter' dropdowns list circulation notices as "name (code)" and offer 'No letter'. (no regression) 2) Give a staff user 'catalogue' + 'manage_circ_triggers' only, with home library A. Log in as them, 'Set library' to B, and open Administration > Circulation triggers. Notice the view is pinned to A, and that adding and editing a trigger saves without a 403. (behaviour is now correct) 3) GET /api/v1/circulation_rules?rules=nosuchrule - notice the error points at /api/v1/circulation_rules/kinds. (behaviour is now correct) 4) Run 'gulp po:update --lang fr-FR'. Notice 'Add new trigger {triggerNumber}', 'No letter' and 'any' now appear in misc/translator/po/fr-FR-messages-js.po (behaviour is now correct) 5) Edit a trigger. Notice the delay's reset button is an 'x' inside the input, left of the chevrons, and clears the delay; the letter's reset button does the same for the notice. (no regression) 6) Notice no visual regression across the list, add, edit, reset and delete screens - select widths, chevrons and modals unchanged. Also run t/db_dependent/api/v1/circulation_rules.t Assisted-by: Claude Opus 5 (Anthropic) Sponsored-by: Glasgow Colleges Library Group <https://library.cityofglasgowcollege.ac.uk> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 40167] New: Curbside pickups - Show link if not configured
by bugzilla-daemon＠bugs.koha-community.org 11 Sep '26

11 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40167 Bug ID: 40167 Summary: Curbside pickups - Show link if not configured Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Right now, it displays a warning message when you navigate to Circulation > Curbside pickups, but don't have them configured for the current branch. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16