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

[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 39045] New: Add translation context for "Active" and "Inactive"
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '25

07 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39045 Bug ID: 39045 Summary: Add translation context for "Active" and "Inactive" Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: f.demians(a)tamil.fr, jonathan.druart(a)gmail.com In French, the translations for "Active" and "Inactive" depend on the gender of the thing that is active/inactive. For example, a currency is feminine so it will be active/inactive, but a supplier is masculine so it will be actif/inactif. I propose to add translation context for "Active" and "Inactive". -- 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 38261] New: JS warning "unreachable code after return statement"
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '25

07 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38261 Bug ID: 38261 Summary: JS warning "unreachable code after return statement" Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: pedro.amorim(a)ptfs-europe.com, tomascohen(a)gmail.com 792 function getTitle(meta) { 793 if (meta.article_title && meta.article_title.length > 0) { 794 return 'article_title'; 795 return { 796 prop: 'article_title', 797 value: meta.article_title 798 }; 799 } else if (meta.title && meta.title.length > 0) { 800 return 'title'; 801 return { 802 prop: 'title', 803 value: meta.title 804 }; 805 } 806 }; -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 37033] New: Plugin intranet_js won't load in Cart popup (intranet-bottom.inc missing)
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '25

07 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37033 Bug ID: 37033 Summary: Plugin intranet_js won't load in Cart popup (intranet-bottom.inc missing) Change sponsored?: --- 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: lmstrand(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org We need to make a modification to the cart view and tried to create a plugin that injects javascript to the cart view. It won't get applied to cgi-bin/koha/basket/basket.pl since it's template is missing it's [% INCLUDE 'intranet-bottom.inc' %] which loads the plugin subs called intranet_js to the browser. I added the code to basket.tt and now the plugin's intranet_js gets applied to the view. This issue may occur in similar popup views elsewhere in the Koha intranet too, where we have decided not to include the intranet-bottom.inc to the browser view. Should this ticket be made a generic one dealing with all similar occurences throughout Koha intranet (Z39.50 search for example)? Is there any downside for having the bottom bar in these views? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 39512] New: Error 500 when applying payout of 0
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '25

07 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39512 Bug ID: 39512 Summary: Error 500 when applying payout of 0 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I was testing something else and did not enter a payout amount, which resulted in an error 500. I think it should result in a warning or error message to tell the staff member that they forgot to enter a value in the payout input. To recreate: 1. Go to a patron account > Accounting 2. Click 'Create manual invoice' 3. Enter an amount 4. Click 'Save and pay' 5. Click 'Confirm' 6. Click 'Transactions' 7. Click 'Payout amount' (should the button even appear if the patron has 0 due?) 8. Click 'Confirm' It should say something like "Please enter a payout amount". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[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 38740] New: Template basket/basket.tt should not end with closing body and html
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '25

06 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38740 Bug ID: 38740 Summary: Template basket/basket.tt should not end with closing body and html Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Since Bug 37033 added INCLUDE 'intranet-bottom.inc' template basket/basket.tt should not end with closing body and html. Those tags are closed by intranet-bottom.inc. Most templates end with this include. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 39630] New: Problems with search for dateaccessioned (ElasticSearch)
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '25

06 Oct '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39630 Bug ID: 39630 Summary: Problems with search for dateaccessioned (ElasticSearch) Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: trevor.diamond(a)mainlib.org QA Contact: testopia(a)bugs.koha-community.org Starting in advanced search, if you select Acquisition date as your search qualifer and enter a date (ex: 2025-03-25) you get more results than expected. If you "search with results" by limiting to Acquisition date, the results refresh with much more reasonable results. The advanced search code is as follows: 523 result(s) found for '2025-03-25' with limit(s): 'date-of-acquisition:("2025-03-25")'. Which indicates that your initial selection of Acq date didn't actually "stick". If you click "edit this search" you are returned to the advanced search screen which shows a keyword search of 2025-03-25, again showing taht your initial selection of acq date isn't being remembered. If you try this series of steps with a different filter (ex. Publication year), you do not see this kind of behavior (the results are correctly limited in the first pass and going back to edit the search shows the selection of Publication Year for your search qualifier). This seems very similar to the activity in Bug 17815 ( https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17815 ) but I saw Zebra mentioned several times there and it was suggested that I open a new bug for elasticsearch. The solution would be for Advanced search to actual utilize and remember the search qualifer when acquisition date is selected. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5