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

[Bug 27428] New: Show the number of records in the bibliographic record detail page with ElasticSearch.
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '26

04 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27428 Bug ID: 27428 Summary: Show the number of records in the bibliographic record detail page with ElasticSearch. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: ivan.dziuba(a)inlibro.com This preference only for OPAC to show the number of records next to search links in the bibliographic record detail page. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 105

[Bug 33413] New: Make staff notices digest-able for OPAC_REG and NEW_SUGGESTION
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '26

04 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33413 Bug ID: 33413 Summary: Make staff notices digest-able for OPAC_REG and NEW_SUGGESTION Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: catrina(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The EmailPurchaseSuggestions and EmailPatronRegistration system preferences should be configurable to send a daily digest of the purchase suggestions or self-registered patrons for a given library. Especially for larger public libraries or consortia, the number of emails triggered by this system preference could quickly become overwhelming but the appropriate staff may still want to be notified when these actions occur. The corresponding notices are NEW_SUGGESTION and OPAC_REG. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 39207] New: Improve usability of search when holding a specific item
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '26

04 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39207 Bug ID: 39207 Summary: Improve usability of search when holding a specific item 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: lauri.hanninen(a)lahti.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 178779 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=178779&action=e… Image showing how user's set library blocks filtering due to allowed pickup locations When filtering for a specific item on holds page using the search bar, it's currently not feasible to filter by user's set library. When entering the user's set library in the search field, search results won't narrow down because they include the active selection in the Allowed pickup locations column which by default is the user's set Library. Filtering by user's own library would be one of the common usages for the search field when placing a hold on a specific item, so it would have more usability if it could be fixed. See attached image as an example. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 42714] New: Koha::Script should automatically log start and end of scripts when they are run
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '26

04 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42714 Bug ID: 42714 Summary: Koha::Script should automatically log start and end of scripts when they are run Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: jake.deery(a)openfifth.co.uk, robin(a)catalyst.net.nz Currently, our scripts/cronjobs are expected to add cronlogaction calls at the start and end to ensure they are recorded in the action logs. This is tricky as we have to maintain these lines in all cron scripts An easier way to do this is to add INIT and END blocks to Koha::Script - these can log the run, and require only one line per file to add the logging. Adding to Koha::Script will mean that any command line script using it will be recorded, but I think this is actually a benefit and makes tracing actions easier -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 42763] New: ERM local title show page does not display link to local bibliographic record
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '26

04 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42763 Bug ID: 42763 Summary: ERM local title show page does not display link to local bibliographic record Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: adolfo.rodriguez(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk When a local eHoldings title has a linked bibliographic record (created via the "Create bibliographic record" checkbox), the show page for that title does not display the "Local bibliographic record" link, even though the biblio_id is correctly stored in erm_eholdings_titles and returned by the REST API. Steps to reproduce: Go to E-resource management > eHoldings > Local > Titles Create a new title, checking "Create bibliographic record" Save and open the title's show page Actual result: No link to the local bibliographic record is shown anywhere on the page. Expected result: A "Local bibliographic record" link pointing to /cgi-bin/koha/catalogue/detail.pl?biblionumber=<id> should appear, as it already does for EBSCO titles in EHoldingsEBSCOTitlesShow.vue (line 21–25). Root cause: The local titles show page is rendered by EHoldingsLocalTitleResource.vue via the generic ResourceShow framework, which only renders fields declared in resourceAttrs. The biblio_id field is not declared there, so the link is never shown — despite the data being present. By contrast, EHoldingsEBSCOTitlesShow.vue uses a dedicated template that explicitly checks v-if="title.biblio_id" and renders the link. Fix: Add biblio_id to the resourceAttrs array in EHoldingsLocalTitleResource.vue with hideIn: ["List"], a hidden guard so it only shows when a biblio is linked, and a link pointing to the catalogue detail page using the existing LinkWrapper mechanism. See also: Bug 35095 (related: the linked biblio record only maps the title field, not other metadata). -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 17387] New: Add an undelete feature for items/biblios
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '26

04 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17387 Bug ID: 17387 Summary: Add an undelete feature for items/biblios Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Some libraries would like to be able to restore items accidentally deleted. This should be possible, rows can be copied over as long as there are checks in place for unique ids. -- You are receiving this mail because: You are watching all bug changes.

1 272

[Bug 28736] New: Better error message when ES fails to understand the syntax of the search query
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '26

04 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28736 Bug ID: 28736 Summary: Better error message when ES fails to understand the syntax of the search query Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: stalkernoid(a)gmail.com "Unable to perform your search. Please try again." error message doesn't provide any information to the user about the problem and can be really confusing, it implies that by simply performing the search again the result may be different somehow, while in reality the search query probably has incorrect ES syntax which will never work no matter how many times you try, asking user to "Please try again" is redundant. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 11175] Show the parent record's component parts in the detailed views
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '26

04 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11175 --- Comment #525 from David Cook <dcook(a)prosentient.com.au> --- Just got bitten by this: +} else { # check if we should show analytics anyway + $show_analytics = 1 if @{$biblio->get_marc_components(1)}; # count matters here, results does not } Records that shouldn't have "Show analytics" links are showing up because other records that use 773 and link by biblionumber/controlnumber still index to Host-item index using 773$t, and the 245$t from my first record gets hits for unrelated records that have indexed their 773$t into Host-item. Fun times. I'll have to look to see if there's any related reports here that just aren't linked to this one... and failing that I'll think of a solution... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38623] New: Suggestion management page does not show preferred name
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '26

04 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38623 Bug ID: 38623 Summary: Suggestion management page does not show preferred name Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Depends on: 28633 Bug 28633 added a "preferred name" field to patrons, which was meant to be displayed instead of the first name (if enabled) whenever a patron name is displayed in the staff interface, with the first name being visible only on the patron's account details page. The purchase suggestions table is still displaying the first name in the "Suggested by", "Managed by", and "Last modification by" columns. The form for editing a purchase suggestion is also displaying the first name for the suggestor and suggestion manager. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28633 [Bug 28633] Add a preferred name field to patrons -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 8179] Receiving multiple order lines at once
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '26

04 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8179 Felicity Brown <felicity.brown(a)montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |felicity.brown@montgomeryco | |untymd.gov -- You are receiving this mail because: You are watching all bug changes.

1 0