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

[Bug 38007] New: Records created through Acquisitions with Acquisitions framework are saved in Default
by bugzilla-daemon＠bugs.koha-community.org 13 May '25

13 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38007 Bug ID: 38007 Summary: Records created through Acquisitions with Acquisitions framework are saved in Default Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To Replicate: 1. Ensure the system preference UseACQFrameworkForBiblioRecords is set to use. 2. Ensure an item is created when order is placed in the vendor configuration. 3. Create a basket and add an empty record. Fill any a few fields. 4. Click on the title of the record from the basket and view the bibliographic detail view. 5. Note the record has been saved as Default even though the record was created with the Acquisitions framework. I would have expected records created through Acquisitions with the Acquisitions framework would have been saved in the Acquisitions framework. While it is possible to find records created in this way by searching a basket, it would be really nice to find records created in acquisitions with the acquisitions framework and to have the record display more accurately. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 35575] New: Acquisition framework fails to display required next 942 $C when defined as mandatory
by bugzilla-daemon＠bugs.koha-community.org 13 May '25

13 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35575 Bug ID: 35575 Summary: Acquisition framework fails to display required next 942 $C when defined as mandatory Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate 1. Ensure the acquisition framework includes the 942 $C. Mark this field as mandatory. 2. Add to basket from a new record (or other method) 3. See the Item type drop down does not display required. With the 942 $C included in the framework, the item type displays the first alphabetically listed option, which may be wrong if the correct option is not selected. In a way this makes the field "required" by default. There is no "blank" option. Is having the first option pre-selected by default desired behavior? Should it default to a blank option instead? Further, if a field is marked as mandatory, shouldn't there be a Required in red next to the field. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 23232] New: Enable the option to use the onscreen keyboard on the basic cataloguing editor
by bugzilla-daemon＠bugs.koha-community.org 13 May '25

13 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23232 Bug ID: 23232 Summary: Enable the option to use the onscreen keyboard on the basic cataloguing editor Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: koha-bugs(a)lists.koha-community.org, m.de.rooy(a)rijksmuseum.nl, testopia(a)bugs.koha-community.org Depends on: 17178, 23231 Bug 17178 introduced the Mottie on screen keyboard https://github.com/Mottie/Keyboard for the advanced cataloguing screen. It would be helpful to have this option available on the standard editor as well. Catalogers may still have the requirement to enter foreign or special characters when in this mode. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17178 [Bug 17178] Add a popup/keyboard shortcuts for diacritics and symbols in the advanced cataloging editor https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23231 [Bug 23231] We display too many layout options for the onscreen keyboard in the advanced cataloguing editor -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. You are on the CC list for the bug.

1 13

[Bug 38452] New: Inventory tool barcodes should not be case sensitive
by bugzilla-daemon＠bugs.koha-community.org 13 May '25

13 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38452 Bug ID: 38452 Summary: Inventory tool barcodes should not be case sensitive Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org I say this because it doesn't appear like we honor case sensitivity for barcodes elsewhere. So, to recreate: 1. Create an item give it a barcode like 'abc123'; 2. Try creating a 2nd item with a barcode: 'ABC123', you get an error 'Error saving item: Barcode must be unique.' 3. Checkin the item 'ABC123', the 'abc123' item successfully checks in. 4. The case doesn't seem to matter elsewhere in Koha ( check-in, checkout, searching, batch tools ) 5. Try the inventory tool and use 'ABC123'. The barcode is not found. If Koha treats 'ABC123' and 'abc123' the same when creating an item, it should probably treat them the same when using the inventory tool. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 35

[Bug 29985] New: Cashup summary shows unexplainable odd amounts
by bugzilla-daemon＠bugs.koha-community.org 13 May '25

13 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29985 Bug ID: 29985 Summary: Cashup summary shows unexplainable odd amounts 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 CC: martin.renvoize(a)ptfs-europe.com I performed some transactions testing bug 27779 in a fresh ktd instance. I used amounts like 4.50 or 10.00 or 1.55, nothing with more decimals, but I still ended up with this: Cash register: This is a register. Period: to 2022-01-31 21:22:40 Type Total Total 0.0499999999999998 Cash -0.0499999999999998 I have no idea how this can happen, since all amounts in my accountlines and account_offsets are only in 5 cent steps. With the patch from 27779 applies it also shows even amounts: Cash register: This is a register. Period: to 2022-01-31 21:22:40 Type Total Refund against Manual fee - 6 Refund against New card fee - 6 Manual fee 4.55 USB Stick 1.5 Total 0.0499999999999998 Cash -0.0499999999999998 As this should only be additions/subtractions, I have no idea how this could happen unless we have a bug somewhere? Also display should be using Price (CurrencyFormat) system preference, but it doesn't, display remains unchanged with FR option. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 31045] New: Add a housebound notification to staff interface
by bugzilla-daemon＠bugs.koha-community.org 13 May '25

13 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31045 Bug ID: 31045 Summary: Add a housebound notification to staff interface 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: estherm(a)sodaspringsid.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Similar to the notification for curbside pickup or purchase suggestions, it would be nice to add a housebound delivery notification reminder. Otherwise staff would need to know, remember, or otherwise maintain a list of patrons who need housebound services outside of Koha. If combined with bug 26545 where patrons can update info or request a delivery through the OPAC, the overall module becomes much more useful. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 30380] New: No suggestions ASKED letter transported by email
by bugzilla-daemon＠bugs.koha-community.org 12 May '25

12 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30380 Bug ID: 30380 Summary: No suggestions ASKED letter transported by email Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org C4/Suggestions line 487 calls GetPreparedLetter with status==ASKED in the letter code parameter, causing warning at line 583 in C4/Letters: No suggestions ASKED letter transported by email Since we have no ASKED notice, we should either check the status and not call Letters or add this notice. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 38396] New: Revert transit status on a hold does not work
by bugzilla-daemon＠bugs.koha-community.org 12 May '25

12 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38396 Bug ID: 38396 Summary: Revert transit status on a hold does not work Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: bdaeuber(a)cityoffargo.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Click the "revert transit status" on a hold allows you to change the pickup location of the item, but the item stays in transit. To recreate: 1. Place a hold for pickup at a different location. 2. Check in the hold to trigger the transfer to the pickup location. 3. Go to the holds table and click "revert transit status" on the hold. Change the location if you wish. 4. Return to the record and note that the item still says it's in transit to the original location. Checking in the location does transfer it properly, but the transit status should actually reset. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 38991] New: Reverting a hold does not cancel the related transfer
by bugzilla-daemon＠bugs.koha-community.org 12 May '25

12 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38991 Bug ID: 38991 Summary: Reverting a hold does not cancel the related transfer Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: r.delahunty(a)arts.ac.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When an item on hold is being sent from one branch to another (to satisfy that hold) and it is reverted (say, after the item appears to be missing in transit) the item remains In transit. The transfer status should be removed so the hold / reservation becomes active again and it will appear in the Holds to Pull feature. Steps to reproduce: 1. In a multi-site setup, identify an existing hold that is In transit (to the chosen pickup location). 2. In the hold select 'Revert transit status'. 3. Return to the biblio and under the Holdings tab, the item will still be marked as 'In transit'. 4. Even logging back in as the item;s home library and selecting Ignore in the transfer modal only sets the status to 'In transit pending'. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 34191] New: Record overlay rule to protect 942 with asterisk being ignored with z39.50 overlay
by bugzilla-daemon＠bugs.koha-community.org 12 May '25

12 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34191 Bug ID: 34191 Summary: Record overlay rule to protect 942 with asterisk being ignored with z39.50 overlay Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To recreate: 1. Create multiple Record overlay rules with Source, z39.50, TAG, protect, skip, skip, skip, skip. 2. Create Record overlay rule Source, *, 942, Protect, skip, skip, skip, skip. 3. Find a bib record and make sure it contains a 942 with selected item type. 4. Replace record via z39.50 (using the basic editor) 5. Edit the bib and change the protected tags in the overlay rules for z39.50. 5. Attempt to save the record. If 942 is a required field, you must select the item type. If that happens, select an alternate item type. The record will save and restore the tags protected through the z39.50 overlay rules. But the record will also save the alternate item type and not protect/restore the 942 tag to the previous item type. The asterisk should protect the 942 tag regardless of the cataloging process. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3