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

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '25

14 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 --- Comment #499 from David Cook <dcook(a)prosentient.com.au> --- Created attachment 184048 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=184048&action=e… Bug 15516: (follow-up) integrate BZ 15516 and BZ 15565 This patch makes DisplayAddHoldGroups and DisplayMultiItemHolds work together, so that you can add multiple items to 1 hold group from the staff detail page, the OPAC detail page, or the OPAC search results. Note: At this time, you can't add multiple items to a hold group from the staff search results. This is due to the existing constraints in request.pl Over the last 10 years, in practice most hold groups have been formed at the OPAC anyway. Test plan: __OPAC search results__ - Enable both DisplayAddHoldGroups and DisplayMultiItemHolds - Go to http://localhost:8080/cgi-bin/koha/opac-search.pl?idx=&q=test&weight_search… - Choose "Gairm" and "Continuous delivery" and click "Place hold" - Checkbox "Treat as hold group" - Click "Show more options" for each record - Click "A specific item" for "Continuous delivery" - Checkbox both specific items for that title - Press "Confirm hold" - Note 3 holds are in the hold group - Cancel all the holds __OPAC detail page__ - Go to http://localhost:8080/cgi-bin/koha/opac-detail.pl?biblionumber=134 - Click "Place hold" - Checkbox "Treat as hold group" - Click "Show more options" - Choose "A specific item" - Checkbox both items - Click "Confirm hold" - Note 2 holds are in the hold group - Cancel all the holds __Staff detail page__ - Go to http://localhost:8081/cgi-bin/koha/reserve/request.pl?biblionumber=134&borr… - Choose "Hold a specific item" - Checkbox "Treat as hold group" - Checkbox both items - Click "Place hold" - Note 2 holds are in the hold group - Cancel all the holds -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '25

14 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 --- Comment #498 from David Cook <dcook(a)prosentient.com.au> --- Created attachment 184047 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=184047&action=e… Bug 15516: (follow-up) Have DisplayAddHoldGroups disabled by default -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '25

14 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 --- Comment #497 from David Cook <dcook(a)prosentient.com.au> --- I think the integration with 15565 might actually be straightforward. Going to try that out shortly... I did notice the sysprefs.sql change defaults to 1 but it should be 0 so that the feature is disabled by default... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '25

14 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 --- Comment #496 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Pedro Amorim from comment #493) > Fresh k-t-d, all patches applied, reset_all (DisplayAddHoldGroups already > enabled): > 1) Search for 'music': > http://localhost:8081/cgi-bin/koha/catalogue/search.pl?q=music > 2) Select the checkbox on the 1st record (Nordic roots) and 3rd record > (Clothes, clothes...) > 3) Click the 'Place hold' button > 4) Search for 'koha (42)' user. Pick that. > 5) Check the 'treat as hold group' checkbox > 6) Select the pickup locations 'Fairfield' for Nordic root, 'Fairview' for > Clothes, clothes... Click 'Place holds'. > 7) Visit the user page: > http://localhost:8081/cgi-bin/koha/members/moremember.pl?borrowernumber=51 > 8) Notice the holds tab marks '1' hold (considering the hold group as one > hold) but lists both holds, with each having the 'part of a hold group' link. > 9) Check-in an item of 'Nordic roots': 39999000003154 > 10) Click 'Confirm hold and transfer'. > 11) Repeat 7) Notice both holds are still present. I would expect the > 'Clothes, clothes...' hold to have been deleted now that the hold group has > been satisfied. So this one is interesting. If you changed branches to "Fairfield" and checked in "Nordic roots", you'd see the other hold get cancelled/deleted. It looks like this code doesn't cancel the other hold until one of the holds is found and waiting. (Currently looking at C4::Reserves::ModReserveAffect) I've double-checked locally and that's how it works in prod, but I could see different libraries wanting different choices. For some, the hold isn't available to patrons until it is waiting on the shelf, so I suppose they could cancel the hold while it's in transit or the item could get lost in transit, and then they might want one of the other holds in the group. It's an interesting one for sure. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '25

14 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 --- Comment #495 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Pedro Amorim from comment #493) > As per my instructions above, for both Staff and OPAC, if the item that > satisfied the hold group becomes "In transit", the other hold in the hold > group is not deleted. Oh that's really interesting! I'll look into that! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 31947] New: Add 'btn-primary' to the main action button where it's missing
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '25

14 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31947 Bug ID: 31947 Summary: Add 'btn-primary' to the main action button where it's missing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com With the staff client refresh, the btn-primary was given a much clearer set of yellow styling.. we should try to add said markup wherever it's missing. This bug servers as a collector. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 32069] New: Make submit button yellow on "create manual invoice"
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '25

14 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32069 Bug ID: 32069 Summary: Make submit button yellow on "create manual invoice" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Blocks: 31947 The other accounting tabs have yellow buttons, but "Create manual invoice" does not. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31947 [Bug 31947] [Omnibus] Add 'btn-primary' to the main action button where it's missing -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 37107] New: Unclear descriptions for DefaultLongOverduePatronCategories and DefaultLongOverdueSkipPatronCategories
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '25

14 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37107 Bug ID: 37107 Summary: Unclear descriptions for DefaultLongOverduePatronCategories and DefaultLongOverdueSkipPatronCategories Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)ptfs-europe.com, philip.orr(a)lmscloud.de The descriptions for the DefaultLongOverduePatronCategories and DefaultLongOverdueSkipPatronCategories system preferences refer to 'overdues' - for example: -"Set the default patron categories to receive overdues to" -"Leave this field empty if you want to process overdues for all patron categories" This makes it sound like the system preferences are about whether patrons receive overdue notices ("receive overdues") or are eligible to have items be considered overdue ("process overdues"), but really they control whether items checked out patrons in these categories are set to a lost value by the longoverdue.pl cron. The system preferences' descriptions should be clarified to make this clear. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 32078] New: We should have an easy way for an administrator to update the encryption keys
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '25

14 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32078 Bug ID: 32078 Summary: We should have an easy way for an administrator to update the encryption keys 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz We now use encryption on a number of Koha database fields and utilise a key sorted in koha-conf.xml.. However, we have no easy way to change key should that key be leaked or found to be to simple to crack. We should add a script to allow updating of our encrpyted values from one key to the next... (or alternatively, perhaps we should allow for an array of keys in our config and update the encryption on access whenever we find an prior key is in use?.. I believe this is what we did when we upgraded from SHA to BCrypt for user passwords). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 37061] New: Allow to define what information is automatically transferred from biblio to a new component record
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '25

12 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37061 Bug ID: 37061 Summary: Allow to define what information is automatically transferred from biblio to a new component record Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: piia.semenoff(a)ouka.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The cataloguing of the music material is in accordance with the RDA. It would be nice to be able to define which information is automatically transferred from the biblio to its component record (more specifically to 773 fields) when you create a new component record. It’s not possible to define through the staff interface what information is transferred from the biblio to the component record, because there is no system preference for these configurations. Fields are hard coded in Koha's source code. (C4\Biblio.pm, prepare_host_field). The information should transfer from biblio to the component record like this: 001 -> 773w 020$a -> 773z 022$a -> 773x 028$b 028$a -> 773o 245$a 245$b 245$n 245$p 245$c -> 773t 264$a 264$b 264$c -> 773d 300$a 300$e -> 773h In this bug by component record I mean e.g. a song of a note or a song of an album. I'm not quite sure what is the right term to use in this case. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19