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

[Bug 42322] New: Collapse sidebar
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42322 Bug ID: 42322 Summary: Collapse sidebar Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com On bug 42190 we discuss the possibility to collapse the sidebar in order to enlarge the screen and specifically the table in the main div. It would be good to have the behaviour available everywhere, not only on the report result view. -- You are receiving this mail because: You are watching all bug changes.

1 184

[Bug 43469] New: Duplicate records in biblio and deletedbiblio tables if deleting records metadata fails
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43469 Bug ID: 43469 Summary: Duplicate records in biblio and deletedbiblio tables if deleting records metadata fails Initiative type: --- Sponsorship --- status: 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: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- A while ago we faced a deadlock problem with our biblio_metadata table. This led to our biblio record deletion background jobs to fail, leaving duplicate records in biblio and deletedbiblio tables, moving biblioitems row to deletedbiblioitems and leaving metadata to biblio_metadata table. While this really is an edge case and happened because our own scripts were interfering delete process of metadata, I suggest that we add rollback to addbiblio.pl in case something goes wrong with delete. Also we should handle FIXME in line 867 and move error message to template alert. This is tricky to reproduce and only way I could think of is to break code in sub _koha_delete_biblio_metadata directly. To reproduce: 1. Create a biblio record. 2. Find sub _koha_delete_biblio_metadata from Biblio.pm and break it e.g. remove one column from SQL query. 3. Attempt to delete biblio. => Error "ERROR when DELETING BIBLIO x : Exception raised - DBI Exception: DBD::mysql::db do failed..." is raised but not as standard template error as in other error cases. 4. Search your biblio from database. => Note that biblio is in both biblio and deletedbiblio table. => Note that biblio has been inserted to deletedbiblioitems table and deleted from biblioitems table. => Note that biblios metadata is still in biblio_metadata table but not in deletedbiblio_metadata table. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 32776] New: Choose to convert oldest reserve or all possible reserves to recalls
by bugzilla-daemon＠bugs.koha-community.org 21 Sep '26

21 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32776 Bug ID: 32776 Summary: Choose to convert oldest reserve or all possible reserves to recalls Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 31415 introduces a script to convert reserves to recalls. By default, it will take the oldest reserve on a record and convert it to a recall. We should be able to customise which reserve(s) are converted to recalls. Options may include: - oldest reserve - one reserve for each issued item available to be recalled -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 12757] Integers in saved SQL report ODT export prepended with single quote
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '26

19 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12757 Janusz Kaczmarek <januszop(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |43571 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43571 [Bug 43571] (Bug 12757 follow-up) In ODS reports, transformation of number-line strings into float should be optional -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 43571] New: (Bug 12757 follow-up) In ODS reports, transformation of number-line strings into float should be optional
by bugzilla-daemon＠bugs.koha-community.org 19 Sep '26

19 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43571 Bug ID: 43571 Summary: (Bug 12757 follow-up) In ODS reports, transformation of number-line strings into float should be optional Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com Depends on: 12757 Target Milestone: --- In the data collected by libraries, there are sometimes strings that "look like numbers" but are actually strings. The change introduced by Bug 12757 is confusing for libraries in such cases. Such strings should therefore not be automatically converted to the float format without user control. Instead, this behavior should preferably be controlled by a global system preference, or possibly by an option for a specific report or export. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12757 [Bug 12757] Integers in saved SQL report ODT export prepended with single quote -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 43564] New: Add ability to pass arguments to plugins in plugins_nightly.pl
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43564 Bug ID: 43564 Summary: Add ability to pass arguments to plugins in plugins_nightly.pl Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: bastien.chauvet(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: kyle(a)bywatersolutions.com, martin.renvoize(a)openfifth.co.uk, tomascohen(a)gmail.com Target Milestone: --- It would be beneficial for plugins_nightly.pl to accept arguments to pass to plugins using the cronjob_nightly() method. As it would allow those plugins to more easily adapt their behaviour depending on the situation. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 22994] New: Elasticsearch ability import mappings and facets settings
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22994 Bug ID: 22994 Summary: Elasticsearch ability import mappings and facets settings 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: black23(a)gmail.com Target Milestone: --- -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 21004] New: Use modal to add and edit notes on receiving orders/shipments page
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21004 Bug ID: 21004 Summary: Use modal to add and edit notes on receiving orders/shipments page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org See bug 20969, but for parcel.pl. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 43489] New: Thesaurus filtering should be scoped by auth_type, not by MARC21 tag position
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43489 Bug ID: 43489 Summary: Thesaurus filtering should be scoped by auth_type, not by MARC21 tag position Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Depends on: 43483 Target Milestone: --- Bug 43483 fixed the most common case of this problem (a blank/undefined 2nd indicator on a 6XX field being coerced to the literal thesaurus value 'notdefined'). This bug tracks the more thorough underlying fix. C4::Heading::MARC21::parse_heading decides whether to compute a thesaurus value purely from the MARC tag position: my $thesaurus = $tag =~ m/6../ ? _get_subject_thesaurus($field) : undef; That means any 6XX occurrence of a name heading (100/110/111/130 used as 600/610/611/630) can still get a thesaurus constraint applied during authority matching whenever indicator 2 is explicitly coded (0-7), even after bug 43483's fix for the blank-indicator case. For example: 100 1_ $a Goddard, Giles 600 10 $a Goddard, Giles $x Criticism and interpretation (indicator 2 = 0, i.e. lcsh explicitly coded) will still search/create against a 'lcsh' thesaurus constraint for the 600 occurrence, while the 100 occurrence has no constraint at all. If the authority created via the 100 field was not recorded with an explicit lcsh thesaurus, the two can again end up as separate authority records, same symptom as bug 43483, just via a narrower path. The real distinction is not "is this tag a 6XX" but "does this heading's auth_type represent a controlled vocabulary term, or a named real-world entity". MARC's indicator-2 thesaurus code exists to disambiguate genuinely separate subject vocabularies (LCSH vs MeSH vs Sears etc) that may define overlapping terms. It has no equivalent meaning for personal names, corporate names, meeting names or uniform titles: NACO name authority records are reused identically regardless of whether the name functions as a main entry (1XX), added entry (7XX/8XX) or subject added entry (6XX) in a given bibliographic record. There is exactly one authority record per real-world entity, not one per (entity, thesaurus) pair. Suggested solution: Replace the tag-position check in parse_heading with an auth_type check. Introduce a small table of auth_types for which a thesaurus is a meaningful concept - genuine subject/vocabulary terms: TOPIC_TERM, GEOGR_NAME, CHRON_TERM, GENRE/FORM, MED_PERFRM and only call _get_subject_thesaurus for a 6XX field whose auth_type is in that set. Name-entity auth_types - PERSO_NAME, CORPO_NAME, MEETI_NAME, UNIF_TITLE, NAME_EVENT - would then never get a thesaurus constraint, in any tag position, even when indicator 2 is explicitly coded. This is more thorough and correct than the blank-indicator fix in bug 43483 because: 1. It closes the remaining gap: an explicitly coded thesaurus indicator on a name-type 6XX field no longer fragments matching either, not just the blank/undefined case. 2. It matches real cataloguing practice (NACO/LCNAF): the thesaurus concept is a property of subject vocabularies, not of names. Scoping by auth_type encodes that directly instead of relying on tag position as a proxy for it. 3. It is symmetric by construction for every current and future name auth_type, rather than requiring each edge case (blank indicator, explicit indicator, UNIMARC vs MARC21) to be patched individually as it is discovered, which is how bug 33277 and bug 43483 each arose. 4. Genuine subject/vocabulary auth_types (TOPIC_TERM, GEOGR_NAME, CHRON_TERM, GENRE/FORM, MED_PERFRM) keep their existing, correct thesaurus-scoped behaviour, so this does not reopen bug 33277 or affect bug 39503's 6XX-to-6XX collapsing logic. C4::Heading::UNIMARC::parse_heading already always returns thesaurus undef, so UNIMARC is unaffected by either bug and needs no change. Test plan: 1. Turn on LinkerConsiderThesaurus, AutoLinkBiblios and AutoCreateAuthorities. 2. Catalogue a bibliographic record with the same personal name in a 100 field and a 600 field where indicator 2 is explicitly coded (e.g. 0 for lcsh), with no existing matching authority. 3. Confirm only one authority record is created and used by both fields, the same as the blank-indicator case fixed by bug 43483. 4. Confirm existing subject heading matching for TOPIC_TERM, GEOGR_NAME, CHRON_TERM, GENRE/FORM and MED_PERFRM auth_types is unchanged (t/db_dependent/Heading.t "_search tests"). Related bugs: Bug 43483 -- Authority linker treats the same name heading differently in 6XX vs 1XX/7XX. This bug depends on it and generalises its fix from "blank indicator" to "any indicator, for name-type auth_types". Bug 33277 -- Do not search using thesaurus when linking non 6XX fields. The auth_type-based check keeps this behaviour for name-type auth_types, so this is not reopened. Bug 39503 -- Linker should always respect thesaurus with LinkerConsiderThesaurus on. Addresses 6XX-to-6XX matching for subject/vocabulary auth_types, unaffected by this proposal. Bug 41714 -- MARC21 authorities thesaurus link hardcoded. Makes the tag-to-auth_type table configurable via frameworks; the auth_type-based thesaurus check proposed here would need to read from that configurable mapping rather than the hardcoded one, if 41714 lands first. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43483 [Bug 43483] Authority linker treats the same name heading differently in 6XX vs 1XX/7XX -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 43312] New: Migrate opac-user.tt to use api-client.js for article request cancellation
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '26

18 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43312 Bug ID: 43312 Summary: Migrate opac-user.tt to use api-client.js for article request cancellation Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 34451 Target Milestone: --- opac-user.tt uses raw jQuery.ajax() for DELETE calls to /api/v1/public/patrons/.../article_requests/.... This needs to be migrated to api-client.js for proper CSRF token handling (bug 34451). -- You are receiving this mail because: You are watching all bug changes.

1 10