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

[Bug 13439] Convert unimarc framework plugins to new style (see also 10480)
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '25

06 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13439 Andreas Roussos <a.roussos(a)dataly.gr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |a.roussos(a)dataly.gr -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36852] New: Enhance Elasticsearch subject, subject as phrase MARC21 index mappings
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '25

06 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36852 Bug ID: 36852 Summary: Enhance Elasticsearch subject, subject as phrase MARC21 index mappings Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz We would like to add the following tags and subfields to the existing subject index for Elasticsearch MARC21, as used by the "subject" and "subject as phrase" advanced search dropdown options: * 600abc (currently 600a) * 610abcdnty (currently 610a and 610t) * 630amnoprsxyz (currently 630n and 630r) Explanation to justify these mappings: * To search subject added entry, personal name ($600), numeration ($b) and titles and other words associated with name ($c). e.g. 600 $a Elizabeth $n I $c Queen of England. * To search subject added entry, corporate name (610), subordinate unit ($b), location of meeting ($c), date of meeting ($d), number of part/section of meeting ($n), title of a work ($t) and chronological subdivision ($y) e.g. 610 $a International Labour Organisation $b European Regional Conference $n (2nd :$d 1968 :$c Geneva, Switzerland). e.g. 610 $a France. $t Constitution. e.g. 610 $a United States $b Army $b Cavalry History $y Civil War, 1861-1865. * To search subject added entry, uniform title (630 $a), number of part/section of a work($n), name of part/section of work ($p), general subdivision ($x), chronological subdivision ($y), geographical subdivision ($z). * Also, search subject added entry, uniform title (630), for medium of performance for music ($m), arranged statement of music ($o), key for music ($r) and version ($s). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 40295] New: Add CI job Koha_Main_MariaDB_update but with lowest MariaDB version (10.3)
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '25

04 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40295 Bug ID: 40295 Summary: Add CI job Koha_Main_MariaDB_update but with lowest MariaDB version (10.3) Change sponsored?: --- Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Continuous Integration Assignee: tomascohen(a)gmail.com Reporter: victor(a)tuxayo.net That would have caught that blocker: bug 40292 So it's about forking Koha_Main_MariaDB_update and switching the DBMS. It should be ok to leave it on main to be sure to not miss DB revs to test. The trade off is the risk of dropping that new MDB 10.3 upgrade job when that version is dropped from main. That's a more general issue of CI going out of sync with: https://wiki.koha-community.org/wiki/System_requirements_and_recommendations To not risk any of the two trade offs above, we would need to have that job on main, 24.11 LTS and 25.05 (as some db rev would be only on 25.05). That would be a waste of resources. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 30933] New: Add a fallback for keeping lists when deleting anonymized patrons
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '25

04 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30933 Bug ID: 30933 Summary: Add a fallback for keeping lists when deleting anonymized patrons Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Follow-up of 11889 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 57

[Bug 34478] Full CSRF protection
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '25

04 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34478 Fridolin Somers <fridolin.somers(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |40306 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40306 [Bug 40306] Use GET in form of value_builder/unimarc_field_4XX.pl -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36577] New: (bug 34478 follow-up) marc21_linking_section.pl not working
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '25

04 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36577 Bug ID: 36577 Summary: (bug 34478 follow-up) marc21_linking_section.pl not working Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P1 - high Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, jonathan.druart(a)gmail.com After applying "Bug 34478: op =~ ^cud- everywhere" the plugin marc21_linking_section.pl stopped working properly. Changes in marc21_linking_section.tt need to be reflected in marc21_linking_section.pl -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[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 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 40303] New: Allow limiting MaxReserves by patron category
by bugzilla-daemon＠bugs.koha-community.org 03 Jul '25

03 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40303 Bug ID: 40303 Summary: Allow limiting MaxReserves by patron category Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: michael.adamyk(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Bug 15524 added the ability to set maximum numbers of holds per patron category in the circulation rules by library. However, there is not a way to limit MaxReserves by patron category regardless of library. This causes difficulty if ReservesControlBranch is set to the item's home library, potentially allowing for up to the library's hold limit from multiple locations. MaxReserves can stop patrons in large consortiums from having very high numbers of holds, but it doesn't allow that limit to be changed based on patron category. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3