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

[Bug 40362] New: Patron API to allow messaging preferences set through patron attribute
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '25

14 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40362 Bug ID: 40362 Summary: Patron API to allow messaging preferences set through patron attribute Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: hdunne-howrie(a)westminster.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com We use Aspen for our self-registration form but we are not able to allow end users to set their messaging preferences via this form but we can add patron attributes, so we would like to be able to set the messaging preferences via patron attributes. Currently we have a workaround using some custom .js in Koha once the record is opened to set the values based on a patron attribute field input, but not possible during self-registration so all end users are default by their patron category messaging preferences which is not always ideal for some end users. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 36306] New: Make Koha UserName configurable how it is created
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '25

14 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36306 Bug ID: 36306 Summary: Make Koha UserName configurable how it is created 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: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be nice to allow libraries to configure how the Koha User Name is created in the system. Libraries have many different ways they use this field, such as patron-picked user name, card number, firstname.lastname, or a totally different value. This would be a nice system preference to allow libraries to identify which works for their library and also would be nice to have it as a patron category choice. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 40358] New: i cant get patorn info. or even checkout ,
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '25

14 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40358 Bug ID: 40358 Summary: i cant get patorn info. or even checkout , Change sponsored?: --- Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: maherahmad1994(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 25498] New: Cannot change owner of list
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '25

14 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25498 Bug ID: 25498 Summary: Cannot change owner of list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Once someone owns a list, there is no way to change the owner. This problem often arises when a library staff member uses an individual account to create a public list, and then they leave their job. A superlibrarian (or otherwise privileged user) should be able to change the owner of a list on demand. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 89

[Bug 40360] New: Patron table column selections in config overridden following patron search
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '25

14 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40360 Bug ID: 40360 Summary: Patron table column selections in config overridden following patron search Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: n.halford-busby(a)lboro.ac.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The column preferences for the patrons table (as configured in Table Settings) are not applied when the user account is selected from a list of potential matches following a patron search. Instead, all columns are visible and ticked in the 'Columns' view. By contrast, when a patron search yields a unique match (for instance, when searching by borrower number or by a unique surname), or when the user is selected from the dropdown (rather than actually running a search), the columns displayed match those set in the Table Settings. It seems to be when the search goes via https://koha-staff.lboro.ac.uk/cgi-bin/koha/members/member.pl?quicksearch=1… term] that the default table settings are overwritten. Once this situation has arisen, the recent enhancement (33484 - "ability to remember user's selected table configuration and search filters for tables") kicks in, so that all subsequent searches in the browser session result in all columns being displayed (unless the user changes the selected columns manually). -- You are receiving this mail because: You are the assignee for the bug. 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 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff --- Comment #500 from David Cook <dcook(a)prosentient.com.au> --- Moving this to "Needs Signoff" as it looks like this is the same as the version that we're running in prod currently, so it is functional, and should be a reasonable base for further work. -- 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 #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