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

[Bug 27300] New: Create a hold group for multiple items in one record
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '25

10 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27300 Bug ID: 27300 Summary: Create a hold group for multiple items in one record 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Some libraries want to be able to create a hold group for multiple items in one record. (There could be a variety of reasons relating to location, itype, etc.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 15851] New: "Analytics: Show analytics" showing regardless of whether they have analytics.
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '25

10 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15851 Bug ID: 15851 Summary: "Analytics: Show analytics" showing regardless of whether they have analytics. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: ed.veal(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl All of records where position 7 of the leader indicates serial automatically display "Analytics: Show analytics" -- regardless of whether they have analytics. To confirm, we linked numerous items to host records in the case where monographic volumes were bound together via the "Link to Host Item" feature, automatically creating 773s. These are not in question and we do not want to make any changes that would affect them. The request is to remove the display "Analytics: Show analytics" for periodical records that do not have analytics. -- You are receiving this mail because: You are watching all bug changes.

1 112

[Bug 26746] New: Variables available for selecting into notices are misleading
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '25

09 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26746 Bug ID: 26746 Summary: Variables available for selecting into notices are misleading Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org The list of variables available to selectively add to a notice can be misleading. They are currently a list of database field names selected by the module which the notice has been assigned to.. however not all notices actually pass all these tables into GetPreparedLetter and so not all variables are always supported and sometimes additional 'hidden' ones are available. We should clarify this and add support for TT variables at the same time. I believe we could/should do this within C4::Letters itself with a configuration block that lists accepted variables (tables, substitutions, loops etc) which can then be used both to construct the lists in the UI and also to check that the calls to GetPreparedLetter are indeed passing in the required/listed variables we list. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 28262] New: Check ins using offline circulation files (.koc) not refunding lost charges
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '25

07 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28262 Bug ID: 28262 Summary: Check ins using offline circulation files (.koc) not refunding lost charges Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com >From a partner: Our branch's lost item fee refund on return policy is set to "yes" and will refund lost charges whenever a lost item is checked in through the normal means. However, when checking in items through the offline circulation (desktop application) the lost fees remain on the patrons' accounts. We've been using the offline application extensively as part of our item quarantining process and now have a lot of lost charges on patron accounts for items that have been returned. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 23547] New: Add column configuration to course reserves table in the OPAC
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '25

07 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23547 Bug ID: 23547 Summary: Add column configuration to course reserves table in the OPAC Change sponsored?: --- Product: Koha Version: unspecified 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 It would be nice if it was easy to hide columns from the course reserves table in the OPAC (example: hide the Link column because it doesn't contain full text links reliably). -- You are receiving this mail because: You are watching all bug changes.

1 22

[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 29403] New: dt_from_string should fail if passed and rfc3339 formatted string when 'iso' is selected as dateformat
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '25

04 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29403 Bug ID: 29403 Summary: dt_from_string should fail if passed and rfc3339 formatted string when 'iso' is selected as dateformat 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Our dt_from_string regex for time is optional.. as such we allow for non-matches.. but we don't check that the string as a whole matches a valid date/datetime string.. thus we don't fail when we should. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 106

[Bug 29718] New: DateTime - our 'iso' is not ISO 8601
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '25

04 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29718 Bug ID: 29718 Summary: DateTime - our 'iso' is not ISO 8601 Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: In Discussion Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)ptfs-europe.com, tomascohen(a)gmail.com In some scripts we are doing unnecessary conversion from string to DT and vice-versa, sometimes several times. For instance, see bug 29711. We have epoch => DT => string => sending to template in 'iso' YYYY-MM-DD HH:MM => DT => string. This is because the stringified version of DT (the real ISO 8601 YYYY-MM-DDTHH:MM:SS) is not supported by our dt_from_string method. There are (at least) two options: * Use DateTime::Format::Strptime In dt_from_string: my $formatter = DateTime::Format::Strptime->new(pattern => '%Y-%m-%d %H:%M:%S'); return DateTime->now( time_zone => $tz, formatter => $formatter, ) unless $date_string; Then later $dt_params{formatter} = $formatter; But that's an overhead for all dt_from_string calls. * add "T?" to $time_re, easy and efficient. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 60

[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 04 Jul '25

04 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