March 2024 - Koha-bugs - lists.koha-community.org

[Bug 31092] New: Upon importing batch records, if a full MARC record is found, only append the items; do not overlay a full MARC record
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31092 Bug ID: 31092 Summary: Upon importing batch records, if a full MARC record is found, only append the items; do not overlay a full MARC record Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: balestrieri(a)monterey.org QA Contact: testopia(a)bugs.koha-community.org When receiving items from our vendors, the full MARC records are sent in batches for import. We would like the ability to have koha only overlay our brief "on order" records that already exist in the system, not our full records already in our system. Currently, the only choice is to overlay ALL or NO records (choices are "Replace, Add, or Ignore") and to append the items, depending on the matching rule used (most users currently match on ISBN when importing books, audiobooks). Apparently, other ils systems have the ability to determine which existing records are brief and which existing records are full, and you can choose to only overlay the brief MARC records, leaving the full MARC records in tact, appending only the items. I understand the definitive markers are in the leader of the marc record. The leader will show the level of marc record it is. Most loaders will have a function to put this as one of the criteria. An example of an incoming Leader: =LDR 01429pam a2200385 i 4500 Position 17 is the encoding level. The above encoding level is blank, so it is a full level record. Encoding levels: Blank - full level record 1 - full level record 2 – less-than-full level record 3 – less than full level record 4 - less than full level record 5 – less than full level record 6 - less than full level record 7 – less than full level record 8 – less than full level (this is a prepublication record) It would be most convenient if koha would have an internal matching rule that allows for the user to overlay only existing records where levels 2-8 are in position 17 on the MARCs, ignoring any records with a "blank" or "1" in position 17 on existing MARCS, with the ability to still append all items. Right now, many of us in aquisitions need to create separate vendor accounts to order "added/existing" items only to avoid the constant overlaying of full MARC records in koha. We know any items arriving from these accounts already have full records in our system, so the vendor does not send full MARCs for any items ordered from these accounts. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 35115] New: ERM - Potential MARC data loss when importing titles from list
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35115 Bug ID: 35115 Summary: ERM - Potential MARC data loss when importing titles from list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: pedro.amorim(a)ptfs-europe.com CC: caroline.cyr-la-rose(a)inlibro.com, jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com To reproduce: 1) Enable ERMModule sys pref 2) Create a new public list, visit: /cgi-bin/koha/virtualshelves/shelves.pl 3) Click "New list" enter name, set public -> public 4) Click "Add items", enter 112\n113\n114 (new line for each), in "Biblio numbers" 5) Notice that all added biblios have quite a few MARC fields 6) Go to packages, visit: /cgi-bin/koha/erm/eholdings/local/packages 7) Create a new package, add a name and hit 'Submit' 8) Go to titles, visit: /cgi-bin/koha/erm/eholdings/local/titles 9) Click "import from list" 10) Pick the package created in 7) 11) On the row of the list created in 2), click "Import" 12) Go back to the list, visit: /cgi-bin/koha/virtualshelves/shelves.pl?op=view&shelfnumber=1 13) Notice all the biblios have been stripped of their MARC data, and only title remains. Setting this as 'major' for now as I don't think this is intended or desired behavour. -- You are receiving this mail because: You are watching all bug changes.

1 32

[Bug 23295] New: Automatically debar patrons if SMS or email notice fail
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23295 Bug ID: 23295 Summary: Automatically debar patrons if SMS or email notice fail 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: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org When the sending of an SMS (or email) notice fails at the Koha level (i.e. before it is passed to the SMS API) then librarians should have the ability to enable automatic restriction (debarment) of patrons prompting them to update their smsalertnumber (or email address) in their library accounts. Adding this ability will tie in nicely with the functionality implemented in bug 13552 and bug 23291. As the enhancement for this bug report would let us restrict when notices failed at the Koha level, whereas 13552 and 23291 would let librarians restrict when notices failed at the SMS API level in batch restriction jobs retrieving patrons by SMS numbers in the SMS gateway report libraries get telling them which notices failed at the SMS API level. So all three enhancements together will mean there will be end-to-end functionality to restrict patrons when SMS notices fail, thereby prompting them to update their smsalertnumber. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 71

[Bug 31744] New: Inventory tool can take a long time and never complete
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31744 Bug ID: 31744 Summary: Inventory tool can take a long time and never complete Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There seems to be a problem with scaling for the inventory tool. More and more often now with bigger libraries we are running into libraries putting too many barcodes into the tool, and timing out the tool, or not getting feedback on the job progress and clicking back and trying again (and again. And again.), eventually causing a denial of service as they tie up all of their plack workers with inventory jobs. Potentially we could put the processing part into the background jobs or work on the performance here some other way so that larger batches could be accommodated? The servers weren't underpowered for this - the libraries were putting in collection-size-appropriate numbers of barcodes. Open to any kind of solution here that would help make this tool more usable for libraries. Cheers, Liz -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 26907] New: Fix POD for C4::Auth::checkauth
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26907 Bug ID: 26907 Summary: Fix POD for C4::Auth::checkauth Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org Multiple problems here: - There are several "private" subroutines (starting with underscore) between the POD and the actual checkauth subroutine, so if you search for "sub checkauth" you might miss that the POD is actually there (I did). - The example of how to use the sub is: ($userid, $cookie, $sessionID) = &checkauth($query, $noauth, $flagsrequired, $type); but the sub is actually looking for more possible arguments: 793 my $authnotrequired = shift; 794 my $flagsrequired = shift; 795 my $type = shift; 796 my $emailaddress = shift; 797 my $template_name = shift; - The POD says "The login page is provided using a HTML::Template". As far as I know that would now be TT, HTML::Template. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 32705] New: Display actual cost in foreign currency and currency from the invoice
by bugzilla-daemon＠bugs.koha-community.org 29 Jul '25

29 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32705 Bug ID: 32705 Summary: Display actual cost in foreign currency and currency from the invoice Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 25655 On bug 25655 we are going to store the cost and currency from the invoice. On this bug we will display them on the invoice summary. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25655 [Bug 25655] Additionally store actual cost in foreign currency and currency from the invoice -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 35087] New: Discount rate does not accept comma as decimal separator
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '25

28 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35087 Bug ID: 35087 Summary: Discount rate does not accept comma as decimal separator Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Hello all, When a comma is used to define the discount rate of a vendor, the data is not recorded (as NULL), it is however recorded if the separator is a point. In the same way that the BZ rectifying the problems linked to the payment of fines (bug 33028) obliges the input with a point I will propose a corrective in this same direction. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 71

[Bug 34159] New: Remove plan by AR_CANCELLATION choice in aqplan
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '25

28 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34159 Bug ID: 34159 Summary: Remove plan by AR_CANCELLATION choice in aqplan Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions 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'm not sure if this is my data, but I see it on my local master as well as on the bywater and ptfs-e sandboxes... When I go to Plan by X in the Funds administration, there is an option to Plan by AR_CANCELLATION, which is weird and uncecessary (and also doesn't work). To recreate: 1. Add a budget 1.1. Go to Administration > Budgets 1.2. Click 'New budget' 1.3. Fill in the form (make sure there are a couple of months between the start and end dates), e.g. - Start date: 01/01/2023 - End date: 12/31/2023 - Description: 2023 - Total amount: 10000 - Make budget active: check - Lock budget: leave unchecked 1.4. Click 'Save' 2. Add at least one fund to the budget, make sure not to choose any statistics 1/2 2.1. Click 'Actions' next to the budget and choose 'Add fund' 2.2. Fill out the form, e.g. - Fund code: PRINT - Fund name: Print material - Amount: 6000 2.3. Click 'Submit' 3. View the planning page, e.g. Plan by months 3.1. Click 'Planning' at the top of the page and choose 'Plan by months' 3.2. In the Filter box on the left, open the 'Select planning type' drop-down menu --> There is one choice called 'Plan by AR_CANCELLATION' I checked all my funds and all the funds in the sandboxes and none have AR_CANCELLATION as a statistic 1 or 2. If you select this option and click 'Submit', it says there is nothing to show. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 35724] New: Define non-standard port numbers for SFTP upload/download in EDI accounts
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '25

28 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35724 Bug ID: 35724 Summary: Define non-standard port numbers for SFTP upload/download in EDI accounts Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org We have a partner library that has one EDI vendor that will only accept Koha connecting on port 10022. Currently Koha will only connect on port 22, so this library cannot download EDI files from this vendor. It would be helpful if libraries could define a non-standard SFTP ports for uploading and downloading, at a EDI account level (not a global level) as different vendors may require different ports to be used. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 34718] New: Input field in fund list (Select2) on receive is inactive
by bugzilla-daemon＠bugs.koha-community.org 28 Jul '25

28 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34718 Bug ID: 34718 Summary: Input field in fund list (Select2) on receive is inactive Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When an order is received, the fund can be edited/changed. The select2 driven fund list has an input field on top, but you can't type into it. It's not clickable. To test: * Create a new order * Create an order line * Close basket * Receive shipment and create invoice * Receive via link in table * Click on the funds list, try to type into the input field right below the current fund * Verify the field is locked. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20