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

[Bug 37926] New: Bookings - "to" untranslatable
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37926 Bug ID: 37926 Summary: Bookings - "to" untranslatable Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com When placing a booking, where we choose the dates of the booking, the "to" between the two dates is not translatable. To get there: 1. In a detailed record, click on the Items tab on the left 2. Where it says Bookable, choose Yes and click Update 3. Click Place booking 4. Find and select a patron to enable the other fields 5. Under Booking dates, choose two dates --> Dates are displayed as date1 to date2 6. Translate the interface gulp po:update --lang fr-CA ./misc/translator/translate update fr-CA 7. In the system preference StaffInterfaceLanguage, select the other language and click Save all I18N/L10N preferences 8. Change the interface in the other language 9. Redo steps 3 to 5 --> Dates are still displayed as date1 to date2 I searched the various po files, but I didn't take the time to check all occurrences of "to", obviously. I mostly searched for "%s to %s" and modals/place_booking.inc. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 38619] New: UNIMARC prices should also be extracted from 073d
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38619 Bug ID: 38619 Summary: UNIMARC prices should also be extracted from 073d Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org When adding a document that does not use 010d as price document, but 071d, the price is not imported from koha since it only checks 010d and 345d. To reproduce: 1 - Create a Koha item, make sure there is neither 010d or 345d 2 - Add a 071d and fill a price 3 - Export the item as marcxml 4 - If you do not have one: in acquisition, create a vendor, a basket associated to this vendor, and a line associated to this vendor 5 - Add a line to any open basket, select: import "from a new file" and select the exported marcxml 6 - The price in 071 is not exported -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 38455] New: UNIMARC XSLT Music incipit is not showing when field 036 is missing
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38455 Bug ID: 38455 Summary: UNIMARC XSLT Music incipit is not showing when field 036 is missing Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: marion.durand(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In file koha-tmpl/opac-tmpl/bootstrap/en/xslt/UNIMARCslim2OPACDetail.xsl the test to display information from field 031 (music incipit) is perform on field 036 (which is unrelated). -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 33856] New: Inventory tool CSV export contains untranslatable strings
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33856 Bug ID: 33856 Summary: Inventory tool CSV export contains untranslatable strings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Depends on: 22135 The "Problem" header row label and the problems themselves are untranslatable as they are added in the inventory.pl file. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22135 [Bug 22135] Inventory tool doesn't export "out of order" problem to CSV -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 35700] New: Holds reminder cronjob --triggered switch does not work as intended if the day to send notice hits concurrent holidays
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35700 Bug ID: 35700 Summary: Holds reminder cronjob --triggered switch does not work as intended if the day to send notice hits concurrent holidays Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: lmstrand(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz If the calendar has concurrent holidays, when holds_reminder.pl cronjob is being ran daily with the --triggered switch and the day the notice should be sent lands on a holiday which is repeated the following days, the cronjob sends holds reminders until the holiday period ends. To reproduce: Reserve an item, receive it at a branch where the reserve was made to. Move the waitingdate and reservedate of the reserve to x days before the reserve was made in the database. Add holidays (single non-repeated days) to the calendar so that the first holiday lands on a date when the hold reminder should be sent. Set up the cronjob to run so that the --days trigger matches the first added holiday using also the --triggered switch: holds_reminder.pl -v --days x --triggered --holidays -c for example. Check that the x:th day from the reserve's waitingdate is a holiday, and the date has following days set as holidays as well. Notice that on the following day/days of the first sent reminder, the message is sent again. Same happens the following holidays. It seems the notice is sent also if there is a repeated holiday following the first single day holiday the message was sent (like if saturdays and sundays were repeated holidays). I guess this could be reproduced easier by moving your system date forward and running the cronscript again. I couldn't reproduce the same bug when moving back the waitingdate of the reserve to simulate a day had passed since the first message for some reason. Notice that modifying the holidays use a cache, so just making changes to the database is not enough for the cronscript to notice the changes made. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 31460] New: Merging Item Groups Loses Groups
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31460 Bug ID: 31460 Summary: Merging Item Groups Loses Groups 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: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl With the new feature of Item Groups, if a library merges two records together, both having Items with Item Groups attached, the merge will only retain the Item Group on the Kept Record. It would be beneficial to libraries that all item information including groups is retained in a merge. Test: 1. Have a record (A) with 3 items. 2. Create an item group with 2 of these items. 3. Have a second record (B) with 4 items 4. Create an item group with 2 of these items. 5. Merge the two records together keeping record A 6. Results will show that all items are moved over to record A, but the item group from record B, is not there. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 25015] New: Staff with Edit Items permission Currently Can Not Edit Items attached to a Fast Add Framework
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25015 Bug ID: 25015 Summary: Staff with Edit Items permission Currently Can Not Edit Items attached to a Fast Add Framework Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If a staff has the permission has only the permission in Cataloging to "Edit Items" currently, they can't edit items attached to a Fast Add bib. What should the change be? Does a staff member need to have Fast Cataloging and Edit Items to be able to Edit Items attached to a Fast Added Bib? And if that is the case, the bug lies with the fact the staff member doesn't know that this bib is a Fast Add bib- the Edit option should not be visible to staff that only have "edit items" and not "Fast Cataloging" Or Is it a library's understanding that the permission "Edit Items" allows All Items can be edited even the items attached to Fast Add Biblios? And if that is the case, then the change lies with how the permissions are coded in Koha. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 25947] New: Improve locked account message
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25947 Bug ID: 25947 Summary: Improve locked account message Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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, kyle.m.hall(a)gmail.com Created attachment 106643 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=106643&action=e… Warning messages in the patron details When using FailedLoginAttempts, a patron's account is blocked after X many failed login attempts on the OPAC. When that happens, a message 'Account has been locked.' appears on the patron account details page. This message does not indicate why or how it was blocked. I suggest we change it to 'Account has been locked due to too many failed login attempts'. Furthermore, the font is dark red whereas the font for other warnings (such as wrong category or unpaid fines) is bright red and bold. To test: 1. Change FailedLoginAttempts to a small number, like 2 2. Go to a patron's account and copy their username (while you're there, change the password and add some fines, too) 3. In the OPAC, try to log in with the username and a wrong password several times 4. Go back to the patron's account in the staff interface 5. Note that there is no indication as to why the patron's account is locked and that the font color and weight does not match the other warnings. Also, there is no button to change the password next to the warning. When a patron has unpaid fines or is in the wrong category, there is a button to either pay/writeoff the fines or change the category next to the warning. I would add a button that says 'Change password' next to the locked account warning. This might be outside the scope of this bug, but I think it would improve usability. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 75

[Bug 35885] New: ERM vendor sort order
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35885 Bug ID: 35885 Summary: ERM vendor sort order Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: Laura.escamilla(a)bywatersolutions.com CC: 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 Currently the vendor drop-down list shows the vendors in the order that they were added to the Acquisitions module. It would be ideal if the vendors were sorted in alphabetical order so that libraries could easily locate their selection. -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 33224] New: OPACHoldsIfAvailableAtPickup and no on-shelf holds don't mix well
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33224 Bug ID: 33224 Summary: OPACHoldsIfAvailableAtPickup and no on-shelf holds don't mix well 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This is the situation: The library wants to prevent on-shelf holds as much as possible, only allowing for transfers if the copy at the patron's library is not available. For example, a record with a checked out copy at Centerville and an available copy at Midway. A Centerville patron should be able to place a hold for pickup at Centerville (the hold will appear on Midway's holds to pull for transfer to Centerville). A Midway patron should not be able to place a hold for pickup at Midway since the Midway copy is available. Does that make sense? This is the setting: - circulation rules allow on-shelf holds only if any unavailable - OPACHoldsIfAvailableAtPickup is set to Don't allow Currently, this allows the Midway patron to place a hold for pickup at Midway. To test: 1. Set up the circulation rule so that on-shelf holds are allowed ('Yes') 2. Create a record with two items, one at Centerville and one at Midway 3. Check out the Centerville item 4. Log into the OPAC with a Midway patron (I used Henry Acevedo) 5. Try to place a hold on the record --> Midway is not a valid pickup location (correct behaviour) 6. Cancel 7. Change the circulation rules so that on-shelf holds are only allowed 'if any unavailable' 8. Try to place a hold on the record from the OPAC again --> The system allows you to place the hold for pickup at Midway (incorrect behaviour) 9. Optionally, check the Holds to pull for Midway (the hold is there, it shouldn't) 10. Optionnaly, check in the Midway item (it is trapped for Henry's hold) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23