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

[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 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 27 Feb '26

27 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 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

[Bug 24364] New: Display item holding library in opac issues
by bugzilla-daemon＠bugs.koha-community.org 16 Feb '26

16 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24364 Bug ID: 24364 Summary: Display item holding library in opac issues 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: matthias.meusburger(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Be able to display the item's holding library in OPAC issues. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 19060] New: Patrons should not get a max fines block auto-renewal notification for items due in the future.
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '26

13 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19060 Bug ID: 19060 Summary: Patrons should not get a max fines block auto-renewal notification for items due in the future. Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: r.delahunty(a)arts.ac.uk QA Contact: testopia(a)bugs.koha-community.org This appears related to 19014. Current functionality in 17.05: Auto-renewal is enabled for specific user and item type combinations. This user has fines in excess of that specified in OPACFineNoRenewalBlockAutoRenewal This user has an item due today, and others due at various times in the future, some many weeks ahead. When the auto-renewal job runs today, Koha is sending an AUTO_RENEWAL email to this user for each of the items on loan, warning that each has failed automatic renewal. Desired functionality in 17.05: When the auto-renewal job runs, Koha should only send an AUTO_RENEWAL failure email to the user for item(s) due for automatic renewal today. Other items are still validly on loan and are not due for renewal. The user is being contacted multiple times unnecessarily and this can be confusing. Ray Delahunty University of the Arts London -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3