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

[Bug 19814] New: Batch Check-in function
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19814 Bug ID: 19814 Summary: Batch Check-in function Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: smichaelxx(a)tlen.pl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hi, in Koha exists function named "Batch Check out" but there is no "Batch Check in". A lot of small libraries don't have self-check station. Maybe a good solution would be adding function "Batch Check in"? Thanks a lot Regards -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 189

[Bug 26288] New: Update the Select2 JS lib to version 4.1.0
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26288 Bug ID: 26288 Summary: Update the Select2 JS lib to version 4.1.0 Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Bug 25727 updated Select2 to the latest stable release (4.0.13). We found some glitches about the width (see bug 25727 comment 19 for instance). It seems that the next 4.1 is going to fix it, but still beta. -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 27364] New: Making previous patron cardnumbers searchable
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '26

22 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27364 Bug ID: 27364 Summary: Making previous patron cardnumbers searchable Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: fiona.borthwick(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 18626 introduced the logging of changes to patron cardnumbers which is great, but this still does not link together previous cardnumbers. Imagine this scenario: A library patron loses their library card. They are issued with a replacement. Old and new cardnumbers are recorded in the Modification log. The old card is found (doesn't matter who finds it) and brought to the library. A member of library staff scan the barcode - get no results. This means they are none the wiser as to who this card belonged to. Would it not be a good idea to allow previous cardnumbers to be searchable? Some libraries may record this information somewhere in the patron record, but a search by cardnumber would be extremely helpful. It would be useful if the cardnumber moved into a linked field automatically when a new cardnumber was entered. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 24910] New: Make it possible to choose see also-authorities in authority finder
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '26

21 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24910 Bug ID: 24910 Summary: Make it possible to choose see also-authorities in authority finder Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When searching for authorities, sometimes you may see the result you want to select in a see also, but it is not possible to *choose* that one. You have to do another search to get it into the results list of auth finder. Wouldnt it be nice if we could somehow add a link to choose them too? The current link allows you to open them, but this seems less useful at least in our case. Would a preference be useful to switch between choosing or opening ? Or should we add a small link? How could we address that best in terms of styling etc? Your feedback is appreciated ! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 22108] New: Items generated through MARCItemFieldsToOrder do not receive values applied in Item Information and Default Accounting Details
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '26

20 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22108 Bug ID: 22108 Summary: Items generated through MARCItemFieldsToOrder do not receive values applied in Item Information and Default Accounting Details Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When adding titles to a basket from a staged file (acqui/addorderiso2709.pl), item and fund choices can be applied item-by-item on the Select To Import tab or can be applied to all titles at once using the Item Information or Default Accounting Details tabs. However, if the library is using MARCItemFieldsToOrder to pull some of these values from vendor-supplied MARC files, Koha will ignore selections made on the Item Information or Default Accounting Details tabs. Nothing in the interface indicates that values selected on those tabs will not be used. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 19838] New: Add system preference for adding text to self registration form
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '26

18 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19838 Bug ID: 19838 Summary: Add system preference for adding text to self registration form Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Some libraries would like to add some explanations to the self registration form. At the moment there is only a system preference for the page that shows after submitting the registration form. It would be helpful to have another that shows on the self registration form itself. -- You are receiving this mail because: You are watching all bug changes.

1 45

[Bug 23054] New: Unable to change priority after reverting hold waiting status
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '26

17 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23054 Bug ID: 23054 Summary: Unable to change priority after reverting hold waiting status Change sponsored?: --- Product: Koha Version: 18.11 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 Target Milestone: --- To Test: - Place a hold for Patron A - Place a hold on same item for Patron B - Check item in, triggering Patron A's hold - Revert waiting status on hold - Confirm holds list shows Patron A at priority 1, Patron B at priority 2 - Use arrow buttons to move Patron B to priority 1 - Query reserves table to confirm Patron B at priority 1, Patron A at priority 2 - Check item in - Patron A's hold triggers, even though Patron B was first in priority -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 20846] New: Suppressed Records Still Appear in Public Lists
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '26

17 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20846 Bug ID: 20846 Summary: Suppressed Records Still Appear in Public Lists Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To test: 1. Add a title to a public list 2. Edit the 942$n to suppress the record 3. Confirm that the record isn't visible in the opac 4. Confirm that the title still shows in the list It'd be great to have suppressed records hidden from lists. Even if the link from the list to the bib takes the user to the blocked record page, showing the title in the list is confusing. -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 24720] New: Remove special characters from beginning of search fields
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '26

17 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24720 Bug ID: 24720 Summary: Remove special characters from beginning of search fields 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: glasklas(a)gmail.com The ElasticSearch icu_collation_keyword has weird sorting behavior when field values with some special character (", - or [ for example) as they appear on top when sorting a-z. This patch strips initial special characters so behaves more like one would expect (and more like collations usually sort things). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 52

[Bug 21303] New: XSLT should look in LDR/18 to know whether to add punctuation or not
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '26

17 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21303 Bug ID: 21303 Summary: XSLT should look in LDR/18 to know whether to add punctuation or not Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I noticed the XSLT sometimes adds or removes punctuation. If the cataloguers already add the punctuation while cataloguing, this causes double punctuation or no punctuation at all where there should be. For instance, I have a record where there is a period (.) at the end of 100$e. So in MARC, it looks like 100 1# a Goscinny, René, d 1926-1977-, e author. In intranet details, it looks like Goscinny, René, 1926-1977- [author.]. There are two periods (and no comma after the date). In the 260 field, the opposite happens. There is a period at the end of 260$c in MARC, but nothing is appearing in intranet results. 260 ## a Paris : b Gallimard jeunesse, c [2014]. In the intranet details, it looks like Paris : Gallimard jeunesse, [2014] There is no period after the date. MARC21 has a code in LDR/18 to indicate whether or not punctuation has been included in the cataloguing. XSLT should obey this code to determine if it should add punctuation or not. LDR/18 possible codes # - Non-ISBD a - AACR2 c - ISBD punctuation omitted i - ISBD punctuation included n - Non-ISBD punctuation omitted u - Unknown -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13