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

[Bug 24381] New: ACCOUNT_DEBIT slip not printing information about paid fines/fees
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '25

04 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24381 Bug ID: 24381 Summary: ACCOUNT_DEBIT slip not printing information about paid fines/fees Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org While the templates suggests it should print the fines/fees paid/changed by the payment, this doesn't work for me on current master. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 126

[Bug 18986] New: High Hold Items with Decreased Loan Period Can' t Be Checked-Out with Self-Check
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '25

03 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18986 Bug ID: 18986 Summary: High Hold Items with Decreased Loan Period Can't Be Checked-Out with Self-Check Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: cslone(a)camdencountylibrary.org QA Contact: testopia(a)bugs.koha-community.org Scenario: A patron has an item with a high number of holds ready for pickup. They come to their library get the item and use the SCO to try to borrow it. When they scan the item they are given the message: Item cannot be checked out. Sorry, this item cannot be checked out at this station. Please see a member of the library staff. Additionally, if they don’t notice the message and scan another item, they are returned their account summary/the check-out screen with neither item checked out to the patron. At best this creates a scenario where there's an inconvenient extra step that the patron has to take in order to get their item. At worst, it can lead to the patron inadvertently taking two items with them that have not been checked-out. For the item that is on hold this can lead to further confusion when the it is returned (Koha will indicate that the item must go back on the hold shelf for the patron that just returned it) or when holds are cleared from the shelf (the item will be listed there but won’t be found). To replicate: 1.) In system preferences, go to Circulation preferences->Holds Policy. 2.) There are five preferences grouped together for decreaseLoanHighHolds, make sure to set the first drop down to Enable and enter the reduced loan period and the number of holds that will trigger the reduction (you can configure the other options as desired). 3.) Place a hold on an item with a patron you can use at self-check and place enough additional holds on the item with other accounts in order to trigger the decreased loan period according to your preferences. 4.) Check-in an item from the record with the holds and confirm the hold for the patron. 5.) Log into self-check with this patron and attempt to check-out the item. 6.) You will be taken to the error message. 7.) Scan the barcode again, you'll be returned to the SCO screen. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 20905] New: Warn from Search.t
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '25

03 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20905 Bug ID: 20905 Summary: Warn from Search.t Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Test passes but look at this warn from getRecords: ok 67 - presence of a transit does not block hold request action (bug 10741) ERROR DECODING RECORD - Tag "50%" is not a valid tag. at /usr/share/perl5/MARC /File/USMARC.pm line 223. : 00295nam a22001217a 45000030004000000050017000040080041000211000018000622450 0570008050%001100137942001200148999001300160OSt20111207151138.0111207t xxu||||| |||| 00| 0 eng d aGanser, Helen aA record containing a punctuation character as a tag aa note 2ddccBK c214d214 at /usr/share/koha/devclone/C4/ Search.pm line 683. ok 68 - search for ti:punctuation returned expected number of records A few lines later in the test, a warning_like also looks for this error. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 24097] New: Don't show claims tab in patron account, when there are no claims
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '25

02 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24097 Bug ID: 24097 Summary: Don't show claims tab in patron account, when there are no claims Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Not every library will want to use this feature - I think it would be nicer if we didn't show the tab when there are no claims, so this is a bit more 'invisible'. It also matches how we handle other tabs. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 21357] New: Filter elisions from index and search terms in Elasticsearch
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '25

02 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21357 Bug ID: 21357 Summary: Filter elisions from index and search terms in Elasticsearch 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: ere.maijala(a)helsinki.fi To make searching easier at least in French, it would be nice to have the default configuration handle elisions properly (e.g. l'avion). Coming up with a proposed patch. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 104

[Bug 24841] New: REST API should check if patron is restricted/debarred
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '25

01 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24841 Bug ID: 24841 Summary: REST API should check if patron is restricted/debarred Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no Bug 17247 "ILS-DI HoldTitle and HoldItem should check if patron is restricted" adds checks to see if the patron is restricted before a hold is placed. These checks are added to C4::ILSDI::Services::HoldItem() and C4::ILSDI::Services::HoldTitle(). As far as I can tell, the same checks are missing from the REST API, specifically for "POST /api/v1/holds". Koha::REST::V1::Holds::add() does call C4::Reserves::CanItemBeReserved() and C4::Reserves::CanBookBeReserved(), but as far as I can tell, those subs do not check if the patron in question is debarred. Am I missing something or is this a bug? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 18303] New: Release team omnibus
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '25

01 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18303 Bug ID: 18303 Summary: Release team omnibus Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: About Assignee: nengard(a)gmail.com Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 25071] New: Explain close budget vs make budget inactive
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '25

01 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25071 Bug ID: 25071 Summary: Explain close budget vs make budget inactive Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation 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 that if you try to close a budget with no unreceived orders, it doesn't work. You have to go edit the budget and make it inactive. I didn't test to see if you close a budget with unreceived orders, if it also makes it inactive or if you have to edit the budget to make it inactive after rolling over your unreceived orders. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 16559] New: [%% ... %%] should not be picked for translation
by bugzilla-daemon＠bugs.koha-community.org 27 Jun '25

27 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16559 Bug ID: 16559 Summary: [%% ... %%] should not be picked for translation Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Examples in Koha 16.05: %s [%% INCLUDE "openlibrary-readapi.inc" bib = { normalized_isbn => normalized_isbn, lccn => lccn, normalized_oclc => normalized_oclc } %%] %s [%% UNLESS hidden.defined('phone') && hidden.defined('phonepro') && hidden.defined('mobile') && hidden.defined('email') && hidden.defined('emailpro') && hidden.defined('fax') %%] In Pootle, a search for [%% has 40 results -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 19523] New: Koha:: Cache changes not passed to all plack workers with in-memory caching.
by bugzilla-daemon＠bugs.koha-community.org 27 Jun '25

27 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19523 Bug ID: 19523 Summary: Koha::Cache changes not passed to all plack workers with in-memory caching. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org REPRODUCE: - $KOHA_CONF shouldn't have any <memcached_* -definitions. This triggers in-memory cache usage. - plack workers is atleast 2 - Change some easily visible syspref, such as 'languages'. The syspref change applies only to the worker thread where the change was made. Other worker threads keep using the old syspref. - Observer that 50% of time the old syspref is used. Other times the new syspref is used. - Reduce plack workers to 1. Observe no issues with syspref change taking effect. Using memcached solves this problem. It is still useful to fix it for those who don't want to use memcached. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12