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

[Bug 23875] New: Elasticsearch - ES - When sorting by score we should provide a tiebreaker
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '25

08 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23875 Bug ID: 23875 Summary: Elasticsearch - ES - When sorting by score we should provide a tiebreaker Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com In ES if we sort by 'relevance' we actually don't pass anything to ES and results are ordered by score. When doing a search limiting only by collection or type, the scores are all the same. This is fine, except that editing any record will then cause a reordering of the results, even though it won't affect the score. We should provide a tie-breaker in the case of equal sort scores -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 54

[Bug 33017] New: SQL comments are not fully ignoring runtime parameters
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '25

07 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33017 Bug ID: 33017 Summary: SQL comments are not fully ignoring runtime parameters Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: david.roberts(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org If you use SQL comments in a report, runtime parameters are not fully ignored. For example: /* WHERE branchcode = <<Library|branches>> */ When the report runs, it correctly ignores this parameter, but it still requires the a library branch to be selected before the report can run. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 33905] New: Username and cardnumber should be unique respectively
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '25

07 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33905 Bug ID: 33905 Summary: Username and cardnumber should be unique respectively Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently Koha allows a user to sign in with either their cardnumber or userid Confusion can arise when a user has a username that is another users cardnumber, and vice versa We should check uniqueness across both of these fields. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 45

[Bug 30719] New: ILL should provide the ability to create batch requests
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '25

07 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30719 Bug ID: 30719 Summary: ILL should provide the ability to create batch requests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com Some interlibrary loan providers, for example Reprints Desk, allow for ILL requests to be submitted in batches. In the Reprints Desk case, a batch is created with the supplier, then requests are then submitted including the batch ID. Obviously, this workflow may differ according to supplier and these differences should be abstracted away into the supplier backend. For core Koha, we should provide the ability for it to recognise if a given backend can process batch requests. If so, we should provide an interface for creating and manipulating batches within Koha, then submitting a batch to the supplier. It should also be possible to view all batches and the contents of a given batch. The funding institution has defined the following workflow for creating and populating batches: - A encapsulating "batch" is created with a name and a requesting borrower - Requests are added to a batch via two methods: - In bulk: - A form which allows the user to paste in a collection of identifiers, such as DOI / PMID etc. - For each of these identifiers: - The request metadata should be populated via API queries to metadata suppliers, for example, PubMed API or LibKey/Browzine. This behaviour is governed by the presence of appropriate plugins. - (Optional) Once the metadata is populated for an item, we check for item availability via any installed ILL availability plugins - Individually: - A regular ILL request form, requests are added to the batch -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 194

[Bug 22815] New: Save item's homebranch in patron's fines list
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '25

06 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22815 Bug ID: 22815 Summary: Save item's homebranch in patron's fines list Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisetteslatah(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- bug 15136 added a column to the fines screen (boraccount.pl) that shows the item's home branch. If the item is deleted the branch information goes away. It would be helpful if that column was filled and the data saved so if the item is deleted the information is not lost. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 33731] New: Add hint to audio alert configuration page that for self checkout pages full URLs must be used
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '25

06 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33731 Bug ID: 33731 Summary: Add hint to audio alert configuration page that for self checkout pages full URLs must be used Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: Academy Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The self checkout pages implement Audio alerts, but you can't pick a sound from the list, but have to enter a full URL instead in order to make them work (see bug 22406). This is not obvious and a little hint would be nice until this can be fixed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 31547] New: Lost item and check-in date
by bugzilla-daemon＠bugs.koha-community.org 03 Oct '25

03 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31547 Bug ID: 31547 Summary: Lost item and check-in date Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aspencatteam(a)clicweb.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 140386 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=140386&action=e… word document for confusing check-in and return date Items that have gone lost from long overdue, and also lost items that have been paid have confusing date checked-in information. Perhaps more information could be added to the checkin date/time - for example in red system could say "long overdue to lost". On the circulation history, when an item has been paid for, instead of having just a return date, it could say in red "Date lost and paid" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 35434] New: Non-superlibrarians should not place holds in other libraries when IndependentBranches is enabled
by bugzilla-daemon＠bugs.koha-community.org 03 Oct '25

03 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35434 Bug ID: 35434 Summary: Non-superlibrarians should not place holds in other libraries when IndependentBranches is enabled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily-rose.francoeur(a)inLibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In the intranet, when the system preference IndependentBranches is enabled, non-superlibrarians can make reservations in other libraries, which they shouldn't be able to do. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 54

[Bug 35590] New: Add the translation of seasonal predictions for a chosen locale
by bugzilla-daemon＠bugs.koha-community.org 03 Oct '25

03 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35590 Bug ID: 35590 Summary: Add the translation of seasonal predictions for a chosen locale 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: emily-rose.francoeur(a)inLibro.com QA Contact: testopia(a)bugs.koha-community.org In “Manage Numbering Pattern” (in Serials), we have the possibility to test a pattern with a specified locale. This works well for days and months (as their translations are handled by DateTime()), but it doesn't work for seasons and their abbreviations. To reproduce the bug: **I recommend using the "English" version of the staff interface, as the translation for the prediction pattern with the staff interface locale doesn't work well (see issues 20511 and 24172).** 1) Navigate to “Serials > Manage numbering patterns” and click on the “Edit” button for the “Seasonal” pattern. 2) Under “Test prediction pattern”: - Set “First issue publication date” to today's date. - Set “Subscription length” to “issues” and input “4”. - Choose a language different from the one used in the staff interface for “Locale” (so any language except English). - Set “Begins with” to 0 (for X) and 2023 (for Y). 3) Click on the “Test pattern” button. - Observe that the season names are still displayed in English. 4) In the first section of the page, within the table, change “Formatting” to “Name of season (abbreviated)”. 5) Click on the “Test pattern” button. - Observe that the season names are still displayed in English. 6) Navigate to a record detail page and click on "+ New" and then "New subscription". 7) Click on the “Next ->” button and then “OK”. 8) Fill in the following fields: - Set “First issue publication date” to today's date. - Set “Frequency” to your preference. - Set “Subscription length” to “issues” and input “4”. - Set “Subscription start date” to today's date. - Select “Seasonal” for “Numbering pattern”. - Choose a language different from the one used in the staff interface for “Locale” (so any language except English). - Set “Begins with” to 0 (for Season) and 2023 (for Year). 9) Click on the “Test pattern” button. - Observe that the season names are still displayed in English. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 40

[Bug 29074] New: DefaultHoldExpirationdatePeriod blank value interpreted as zero
by bugzilla-daemon＠bugs.koha-community.org 03 Oct '25

03 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29074 Bug ID: 29074 Summary: DefaultHoldExpirationdatePeriod blank value interpreted as zero Change sponsored?: --- Product: Koha Version: master 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 Depends on: 26498 If DefaultHoldExpirationdate is on and DefaultHoldExpirationdatePeriod is blank, the blank is treated as a zero and all holds are created with an expiration date of today. I'm not sure what the best answer is. We could: - add some text to the syspref to make clear that a blank is treated as zero - make it always save and display a zero when you try to save a blank or - make it treat a blank as disabled (and then add some text to the syspref to tell people that) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26498 [Bug 26498] Add option to set a default expire date for holds at reservation time -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 37