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

[Bug 22415] New: Koha::EDI should not use Log::Log4perl directly
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22415 Bug ID: 22415 Summary: Koha::EDI should not use Log::Log4perl directly 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- We have Koha::Logger for instantiating Log4perl loggers now.. it should be used here too. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 22458] New: PatronSelfRegistrationEmailMustBeUnique disallows self modification requests if multiple accounts share an email address
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '26

27 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22458 Bug ID: 22458 Summary: PatronSelfRegistrationEmailMustBeUnique disallows self modification requests if multiple accounts share an email address Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: jrobb(a)sekls.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- PatronSelfRegistrationEmailMustBeUnique causes unexpected behavior on the patron self modification screen ("your personal details") in the OPAC. When enabled, the system preference blocks existing accounts from submitting account modification requests if the primary email associated with the account is also associated with another account in the database. This means if a parent account and a child account both use the same email address, neither can submit account modification requests via the OPAC. This system preference should only affect new self registered accounts. To reproduce this behavior: 1. Set PatronSelfRegistrationEmailMustBeUnique to 'Consider' 2. Create two different accounts with the same primary email address 3. Log into the OPAC with either account 4. Visit "your personal details" 5. Make a change unrelated to email address and submit 6. The submission is blocked with a message about duplicate email addresses -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 17338] New: waitingreserves.pl should keep you on the same tab when cancelling a hold
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '26

26 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17338 Bug ID: 17338 Summary: waitingreserves.pl should keep you on the same tab when cancelling a hold Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When you cancel a hold on the Hold(s) over tab, and the process is done, it puts you back on the Hold(s) waiting tab. It should keep you on the same tab. It would also be nice if the search box is used that it would keep the focus. We use the following jQuery to help streamline the cancelling process: //Default Holds awaiting pickup to Holds over tab $("#holdso form[action='waitingreserves.pl']").attr("action","waitingreserves.pl#holdsover"); if (window.location.href.indexOf("cgi-bin/koha/circ/waitingreserves.pl#holdsover") > -1) { $("form[action='waitingreserves.pl']").attr("action","waitingreserves.pl#holdsover"); } setTimeout(function() { $("#holdso_filter input").focus(); },10); //End default tab -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 20965] New: Batch patron anonymization logic is flawed
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '26

26 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20965 Bug ID: 20965 Summary: Batch patron anonymization logic is flawed 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org There are two issues here: 1) The tool suggests you can limit by library and checkout date but in fact, the library is not the patrons' library but the library the items were issued at. This is not clear from the UI. 2) When it comes to the actual anonymisation, although we've got a filtered list of Patrons by issues before X and at Library, we then delete ALL issues before X by any of the Patrons selected by the previous query, regardless of which library the checkout took place and thus we ignore the selected Library. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 22459] New: Shibboleth create/sync: Allow mapping of extended patron attributes
by bugzilla-daemon＠bugs.koha-community.org 24 Feb '26

24 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22459 Bug ID: 22459 Summary: Shibboleth create/sync: Allow mapping of extended patron attributes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Depends on: 18507 Target Milestone: --- It woudl be great if extended patron attributes could be mapped for provisioning with Shibboleth as well. One use case would be a unique key, that is also used/neded for patron imports and stored in an unique extended patron attribute. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18507 [Bug 18507] Shibboleth auto-provisioning - Sync -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 23650] New: Multiple opac-restrictedpage.pl pages
by bugzilla-daemon＠bugs.koha-community.org 23 Feb '26

23 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23650 Bug ID: 23650 Summary: Multiple opac-restrictedpage.pl pages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Would like there to be the option to create multiple opac-restrictedpage.pl pages so that depending on patron or library, this information could be custom. Would need: * A way to identify and code for each page * A way to specify which patron types or branches could access each page. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 20628] New: Search result highlighting not working with truncated search terms
by bugzilla-daemon＠bugs.koha-community.org 23 Feb '26

23 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20628 Bug ID: 20628 Summary: Search result highlighting not working with truncated search terms Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This specific issue may fall within the bounds of this larger bug: Bug 11270 - Search Result highlighting should be refactored https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11270 Search terms are not highlighted in search results if the terms are truncated. For example, the search kw:mold will show results with every instance of "mold" highlighted, even if it appears within a larger string like "molding." But a search for kw:mold* or kw,rtrn:mold will not show any highlighting in the search results. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 18148] New: Chronological order for public lists in OPAC
by bugzilla-daemon＠bugs.koha-community.org 17 Feb '26

17 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18148 Bug ID: 18148 Summary: Chronological order for public lists in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: alexandre.breton(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org Hi, Some librarians ask us to have public lists in chronological order rather than in alphabetical order because some schools will have to kept them there for a long time. This results in a big list with many pages on which is more difficult to find the good list. 1) Go in an OPAC interface 2) Go to "Lists" normally in top left corner 3) A small list appears from the top of the screen, observe that this list is by modification date (not alphabetical order) 4) Clic then on public lists 5) Observe that all lists created are in alphabetical order and their order cannot be changed We are wondering if it's possible to have some sorting options for the results list like in the staff client interface. There, you can change for chronological (modification or creation date) but also by owner order. Thanks for helping us, Alexandre from CCSR -- You are receiving this mail because: You are watching all bug changes.

1 59

[Bug 18450] New: Renew in header bypasses hold block and renewal limits
by bugzilla-daemon＠bugs.koha-community.org 17 Feb '26

17 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18450 Bug ID: 18450 Summary: Renew in header bypasses hold block and renewal limits Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When you renew an item on hold, it allows you to bypass the hold, even if you don't allow it elsewhere. It also bypasses renewal limits set in Circulation Rules. Does not honor AllowRenewalLimitOverride preference if set to Don't allow. Does not honor AllowRenewalIfOtherItemsAvailable if set to Don't allow. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 71

[Bug 23355] New: Till Cashup Routine
by bugzilla-daemon＠bugs.koha-community.org 16 Feb '26

16 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23355 Bug ID: 23355 Summary: Till Cashup Routine Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature 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 addition of cash registers in bug 23321 it would be helpful to have a workflow to ease the 'cashup' process. (i.e. matching up cash register contents at the end of the day with the sum of the transactions having taken place.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 199