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

[Bug 20573] New: Patron receives membership expiry notice but 'will expire soon' alert doesn't show for staff at checkout
by bugzilla-daemon＠bugs.koha-community.org 27 Jul '26

27 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20573 Bug ID: 20573 Summary: Patron receives membership expiry notice but 'will expire soon' alert doesn't show for staff at checkout Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: jyorio(a)esilibrary.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We've seen a situation a few times now, where a patron comes into the library and informs the staff that they received notice that their account is going to expire, but when staff go to the patron's account and click checkout, the message, "Attention: Expiration: Patron's card will expire soon. Patron's card expires on ...", doesn't appear. This issue happens when the patron comes into the library exactly 30 days from their expiration. In this case, MembershipExpiryDaysNotice = 30 days and NotifyBorrowerDeparture = 30 days. So for example, the patron's expiration date is 05/11/2018. On 4/11/2018 the patron gets their notice, as expected. They come into the library on 4/11/2018 and the checkout message alerting staff to the impending expiration message doesn't show. Checking the same account on 4/12/2018 shows the message "Attention: Expiration: Patron's card will expire soon. Patron's card expires on 05/11/2018 Renew or Edit Details" on the checkout screen. I would expect the staff to be alerted at checkout on 4/11/2018 since the patron has been notified. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 26279] New: Bridge 3D item type image is there twice
by bugzilla-daemon＠bugs.koha-community.org 27 Jul '26

27 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26279 Bug ID: 26279 Summary: Bridge 3D item type image is there twice Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration 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 Bug 23148 changed the images for the Bridge collection. One image is there twice: realia.png and 3D_art.png (the bust). The names are different, but the image is the same. I would remove one of the two. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 27917] New: Make it clear that standing orders cannot create items at point of ordering
by bugzilla-daemon＠bugs.koha-community.org 26 Jul '26

26 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27917 Bug ID: 27917 Summary: Make it clear that standing orders cannot create items at point of ordering Change sponsored?: --- Product: Koha Version: master 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 When creating a basket, one chooses whether one wants to create item records when ordering, when receiving, or when cataloging. If your basket is a standing order basket, then it cannot create items when ordering. Koha will allow you to pick "placing an order" for when to create items for a standing order basket, but then will not create the item. When creating a basket, we should not allow one to choose "placing an order" for "Create items when" if one has checked the Standing Order box. We should also not allow one to select default for "Create items when" when making a standing order basket if the AcqCreateItem syspref is set to "placing an order." -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 30803] New: output_error should not assume a 404 status
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30803 Bug ID: 30803 Summary: output_error should not assume a 404 status 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org See comments on bug 30261. > There is a fundamental flaw in output_error: > output_with_http_headers $query, $cookie, $template->output, 'html', > '404 Not Found'; > Although we pass $error, it always outputs a 404. I tried sending a 403, and > it does not work! > > The 404 from output_error is caught by Plack middleware and it will output > the 404 error document. In this case the OPAC 404 error document! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29

[Bug 30261] New: opac/tracklinks.pl renders 404 incorrectly
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30261 Bug ID: 30261 Summary: opac/tracklinks.pl renders 404 incorrectly 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org As per https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23329#c87, tracklinks.pl will try to generate an intranet 404 instead of an OPAC 404 if the script is visited without the syspref being activated or if the URL is not a valid one to redirect to. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 36

[Bug 25551] New: [OMNIBUS] Some tests are failing randomly
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25551 Bug ID: 25551 Summary: [OMNIBUS] Some tests are failing randomly Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Keep this open to group tests that are failing randomly -- You are receiving this mail because: You are watching all bug changes.

1 89

[Bug 25778] New: koha-plack --restart causes PERL5LIB to grow with duplicate entries
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25778 Bug ID: 25778 Summary: koha-plack --restart causes PERL5LIB to grow with duplicate entries Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com Line 395 in koha-lack "PERL5LIB=$PERL5LIB:$KOHA_HOME/installer:$KOHA_HOME/lib/installer" causes PERL5LIB to grow with duplicate entries for /usr/share/koha/installer and /usr/share/koha/lib/installer when running in production. Note that this does *not* happen when running in dev, when using koha-testing-docker for instance. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 26434] New: Plugin dirs duplicates in @INC with plack
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26434 Bug ID: 26434 Summary: Plugin dirs duplicates in @INC with plack Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Plugin dirs defined in koha-conf.xml are added to @INC in order to compile perl code. Looks like with plack those dirs are added several times. This may lead to an error "INCLUDE_PATH exceeds 64 directories". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 27834] New: CircControl syspref is used wrong in TooMany function C4::Circulation
by bugzilla-daemon＠bugs.koha-community.org 24 Jul '26

24 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27834 Bug ID: 27834 Summary: CircControl syspref is used wrong in TooMany function C4::Circulation 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: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The CircControl syspref description says > Use the checkout and fines rules of > PickupLibrary: the library you are logged in at. > PatronLibrary: the library the patron is from. > ItemHomeLibrary: the library the item is from. This is mostly true but there is one exception in the TooMany function where it actually doesn't just change which libraries rules are used but how the the calculation is performed. With PatronLibrary set the behaviour is as expected by reading the syspref description. However with the setting PickupLibrary the behaviour changes now, instead of just using the rules of the pickup library we also only take into account the loans in the pickup library when calculating whether we are over the checkout limit or not. The same happens with ItemHomeLibrary where we instead calculate the patron's checkouts in the home library of the item being checked out. We should really try to fix this either by a) showing that ItemHomeLibrary and PickupLibrary is unacceptable and no one actually wants that, that would allow then making the behaviour similar as what it is to PatronLibrary (so just selecting the right circ rule instead of changing calculation method). b) Provide a new syspref for changing the calcutation method when PickupLibrary or ItemHomeLibrary CircControl values are used, and set it on upgrade enabled as default. Ps. svc/letters/preview might use CirControl wrongly as well, I'm not 100% I didn't quite understand but as for other usages of CircControl syspref I grepped where it was used and it correctly only changed the circ rules to be used instead of changing behaviour. So in addition to TooMany we might have to do some changes to svc/letters/preview if it turns out it changes behaviour as well. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 47

[Bug 29653] New: Return claims on deleted items
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '26

23 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29653 Bug ID: 29653 Summary: Return claims on deleted items Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: mspagnuolo(a)nrhtx.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When an item that has been claims returned previously is deleted, the item no longer shows on the patron's account. I would prefer Koha to leave the name of the item or a place holder to be able to track claims returns better. Or perhaps a counter that is not dependent on the item being in the system. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12