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

[Bug 30271] New: Allow distinct ILLHiddenRequestStatuses config for view from patron record
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30271 Bug ID: 30271 Summary: Allow distinct ILLHiddenRequestStatuses config for view from patron record Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com The system preference ILLHiddenRequestStatuses is great for hiding completed ILL requests from the main ILL request page (/cgi-bin/koha/ill/ill-requests.pl). It also applies to the view of ILL requests within a patron record (/cgi-bin/koha/members/ill-requests.pl). It'd be helpful if those two views could have distinct settings so one could easily hide completed requests from the full view but see them in a specific patron's history. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 33193] New: Book cover image visibility depends on the order of 856 fields
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33193 Bug ID: 33193 Summary: Book cover image visibility depends on the order of 856 fields Change sponsored?: --- Product: Koha Version: 22.11 Hardware: PC OS: Windows Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: tuomas.kunttu(a)kouvola.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Book cover link is in Marc field 856 and book description link is in another 856 field. Whether the book cover image is visible depends on the order in which the data is catalogued. Test: 1. System preferences: CustomCoverImages: display and CustomCoverImagesURL: {856$u} 2. Catalogue following data to a record: 856 42 u https://sopimusasiakkaat.booky.fi/description.php?ean=9789518734263 q text z Description 856 42 u https://sopimusasiakkaat.booky.fi/image.php?size=medium&id=9789518734263 q image z Cover image 3. Save and view record 4. Book cover is not visible in record's normal view nor in search results list. 5. Change the order of 856 fields: 856 42 u https://sopimusasiakkaat.booky.fi/image.php?size=medium&id=9789518734263 q image z Cover image 856 42 u https://sopimusasiakkaat.booky.fi/description.php?ean=9789518734263 q text z Description 6. Save and view record 7. Book cover is visible in record's normal view and in search results list. Book cover image should be visible regardless of the order in which the 856 fields are catalogued. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 20344] New: Transferring an item while on hold results in a transfer were the destination is the same as the source
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20344 Bug ID: 20344 Summary: Transferring an item while on hold results in a transfer were the destination is the same as the source Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor.grousset(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com 1. Check out an item 2. Place a hold on the specific item with a pickup at a different branch 3. Check in: Confirm hold and transfert 4. Check the branchtransfers table to ensure that the transfert is here SELECT * FROM branchtransfers order by datesent DESC LIMIT 10; 5. Home › Circulation › Transfers 6. Create a transfer identical as the existing one 7. You should see «Item is already at destination library.» 8. Check the branchtransfers table 1. First one should have been canceled «Canceled, new transfer from A to A created» 2. Another one should have been created from A to A 3. These 2 things are the issue. Because doing the same without a hold - doesn't create a new transfer - doesn't cancel the first one -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 38336] New: Confusion between 099 and 942 field in UNIMARC framework
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38336 Bug ID: 38336 Summary: Confusion between 099 and 942 field in UNIMARC framework Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl I believe there is something wrong in UNIMARC default framework (https://github.com/Koha-Community/Koha/blob/main/installer/data/mysql/en/ma… ) We have 2 fields for "local" data (specific to Koha) at biblio level : 099 and 942 And the same pieces of information are present in subfields of both fields : - 099$x and 942$0 (Number of issues => biblioitems.totalissues) - 099$s and 942$s (Serial record => biblio.serial) - 099$t and 942$c (Koha item type => biblioitems.itemtype) I suppose it is an error, because it makes no sense... And note that the 099 field in UNIMARC framework is called "local dates", so it should not contain information about item type or number of issue. Do you think we could remove safely from the default templates 099$x, 099$s, 099$t ? I don't know if those values may be harcoded somewhere in the code. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 77

[Bug 24782] New: Calendar edit only applies to first day
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24782 Bug ID: 24782 Summary: Calendar edit only applies to first day Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)outlook.com QA Contact: testopia(a)bugs.koha-community.org When editing holidays edit only applies to first day (from date). To test: 1. Add holidays on range e.g from 04/03 to 06/03 2. Try edit these holidays so that from date is 04/03 and to date is set to 06/03 3. Save => Only 04/03 is changed There should be option to edit holidays on range. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 30834] New: Trigger nightly reindex with a syspref
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30834 Bug ID: 30834 Summary: Trigger nightly reindex with a syspref Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org Reindexing (at least with Zebra) leads to search not working for some duration of time, depending on the size of the catalogue. So often you want to do reindexing at night, when use of Koha is low. But remembering to start the indexing process before you go to bed at night is error prone. We could have a syspref called something like "DoReindexInTheMiddleOfTheNight", and a cronjob that runs "in the middle of the night", and checks the syspref. - If it has been set to "on", a reindex is triggered and the syspref is reset to "off". - If it is set to "off", nothing happens. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 37541] New: Changing PIN after turning on forced PIN reset results in setting of NEVER
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37541 Bug ID: 37541 Summary: Changing PIN after turning on forced PIN reset results in setting of NEVER Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: chanel.wheeler(a)yavapaiaz.gov QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org We set up a new patron category with an expiration date of 90 days. We then moved the shared staff accounts over to this new category and set a manual expiration date of a few weeks out. We then went into one of these staff accounts and manually changed the PIN. Now on the patron detail page, it shows their PIN Expires as NEVER. It should show either the manual expiration date we'd already set, or a new date 90 days out. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 20472] New: Working title
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20472 Bug ID: 20472 Summary: Working title Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 91

[Bug 20570] New: Add script to complete scanned article requests
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20570 Bug ID: 20570 Summary: Add script to complete scanned article requests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 33070] New: Get rid of Koha::Patron->can_edit_item and use can_edit_item_from instead
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '26

23 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33070 Bug ID: 33070 Summary: Get rid of Koha::Patron->can_edit_item and use can_edit_item_from instead 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Bug 20256 introduced a pattern we are trying to avoid for a long time now (old patchset). It should be refactored and cleaned. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15