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

[Bug 41276] New: Auto calculation of patron expiration date when editing patron does not follow BorrowerRenewalPeriodBase
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '25

19 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41276 Bug ID: 41276 Summary: Auto calculation of patron expiration date when editing patron does not follow BorrowerRenewalPeriodBase Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com The system preference BorrowerRenewalPeriodBase defines how Koha calculates a patron's expiration date when renewing their account (either by clicking Renew in the staff interface or via the membership_expiry cron). However, Koha will also calculate a new patron expiration date when saving a patron without an expiration date defined. That calculation does not follow the syspref at all. Instead, it calculates differently depending on whether or not the patron registration date is visible in the patron edit screen. To recreate: 1 - confirm patron registration date is *not* hidden with BorrowerUnwantedField 2 - edit a patron, clear their expiration date, and save 3 - confirm their new expiration date was calculated from their registration date 4 - set BorrowerUnwantedField to hide registration date 5 - edit a patron, clear their expiration date, and save 6 - confirm their new expiration date was calculated from the current date This variation of behavior is not particularly clear or expected. It would make more sense to follow BorrowerRenewalPeriodBase when saving a patron with a blank expiration date. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 41218] New: Enrollment fee can be charged twice when changing category of expired patron
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '25

19 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41218 Bug ID: 41218 Summary: Enrollment fee can be charged twice when changing category of expired patron Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com When a patron's account is expired and their category needs to be changed to one that charges an enrollment fee, they end up with two fees if their category is changed before they are renewed. It's unrealistic to expect staff to remember to always renew the patron before changing their category. To recreate: - have an expired patron - have a category that charges an enrollment fee - edit your patron to move them into your category - confirm your patron has been charged the enrollment fee - renew your patron - confirm your patron now has a second enrollment fee charge Possible solutions: - Do not charge an enrollment fee on category change for expired patrons - Ask the user whether or not the charge the enrollment fee on category change for expired patrons - Force renewal of the patron on category change -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 12141] On Display Module
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '25

19 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12141 Rhonda Kuiper <rkuiper(a)roundrocktexas.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rkuiper(a)roundrocktexas.gov --- Comment #32 from Rhonda Kuiper <rkuiper(a)roundrocktexas.gov> --- Our library is very interested in something for displays! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41259] New: The system preference ILLOpacbackends does not work
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '25

19 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41259 Bug ID: 41259 Summary: The system preference ILLOpacbackends does not work Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com, pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com The subroutine opac_available_backends does not work as expected. Expected behavior: - If user is logged, return list of backends that are 1) installed and 2) listed in ILLOpacbackends Actual behavior: - If user is logged in, - If ILLOpacbackends is empty, returns all backends - If ILLOpacbackends contains several values, return no backend As the Standard backend is always available, it will be enabled by default in OPAC, and needs to be disabled by setting ILLOpacbackends to something that isn't a substring of "Standard". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 22178] New: Add start and end date for repeated holidays
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '25

19 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22178 Bug ID: 22178 Summary: Add start and end date for repeated holidays 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- When weekly or other repeating holidays are changed it will always effect dates in the future, but also in the past. For fine calculation and other reasons this can cause problems. It would be nice if it would possible to start and and repeated holidays at specific dates. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 33190] New: Add search history button to advance search form if EnableSearchHistory keep
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '25

19 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33190 Bug ID: 33190 Summary: Add search history button to advance search form if EnableSearchHistory keep 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: adam.styles(a)esa.edu.au QA Contact: testopia(a)bugs.koha-community.org Created attachment 148047 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=148047&action=e… screen shot of search history button in koha dev box as preview Hi All, I believe the 'search history' feature to be quite useful in daily repeated search work flows, further to this it is a feature fairly hidden behind a drop down UI in the top right when logged in. Therefor to promote the use of this valuable tool and also to improve it's discoverability, I propose the follow new enhancement. User story: * Add 'search history' button to advanced search button groups if 'EnableSearchHistory' sys pref is set to 'keep' Key logic: * If 'EnableSearchHistory' sys pref is set to 'keep' (this is an existing sys pref), an additional 'search history' button will populate at the of the current advance search buttons group * This new button element makes use of the existing syntax for other button on page and loads the font awesome 4.7 history icon which aligns with the buttons action. * The button will not display unless 'EnableSearchHistory' sys pref is set to 'keep', which makes use of a IF statement in the advsearch.tt template file at around line 100 ish (see patch) ``` [% IF Koha.Preference('EnableSearchHistory') %] <div class="btn-group"> <a href="/cgi-bin/koha/catalogue/search-history.pl" class="btn btn-link"><i class="fa fa-history"></i> search history</a> </div> [% END %] ``` I have tested in Koha dev box v22 and all works well. I will create test plan in patch commit message. I am creating my first patch for this very soon, just reading coding guidelines to ensure I patch as community expects. See attached screen shot. I welcome feedback. Thanks. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 36434] New: Use a keyword that will be secretly included in all OPAC bibliographic and authority searches
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '25

19 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36434 Bug ID: 36434 Summary: Use a keyword that will be secretly included in all OPAC bibliographic and authority searches 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Libraries might repurpose their OPAC to only search certain records. These records might still have relevant collection, item type, shelving location information, so it doesn't work to use these fields to filter OPAC searches on. It might be easier to add a 'keyword' to the MARC for these records, and have Koha secretly apply this keyword to the search, when switched on. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 36007] New: Add the ability to batch edit in Course Reserves
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '25

18 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36007 Bug ID: 36007 Summary: Add the ability to batch edit in Course Reserves Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be nice to have the ability to batch edit in course reserves. A scenario could be, a course is reactivated, the items in the course are the same, but they all need to be relocated for the course is happening at a different branch, or a different reserve location. A batch edit would allow staff to retain the list of items in the course, but easily update the new course reserves values. At this time, each item would need to be individually edited. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 27464] New: Extend functionality of AllowHoldsPolicyOverride to prevent some overrides
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '25

18 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27464 Bug ID: 27464 Summary: Extend functionality of AllowHoldsPolicyOverride to prevent some overrides Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: madamyk(a)ckls.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If one tries to create a "local use only" item type, there isn't a good way to make it impossible to place holds for anywhere other than its home branch. Setting restrictions on it in Circ rules allows any staff member with permissions to override the hold restrictions. Another option is setting an item to a lost status, but this is certainly not ideal: it clears the status every time the item is scanned, and it affects how it appears in the OPAC. What if there were a way to have finer control over the AllowHoldsPolicyOverride system preference? For instance, allow hold overrides as a separate permission for overriding circulation rules vs. overriding patron restrictions. It seems logical that overriding a restriction to check out to a patron is quite a bit different from ignoring specific circulation rules (if that makes sense). Perhaps another way to work around this would be a checkbox in the circulation rules with an option to "Ignore staff overrides" or something similar? It could be turned on or off for each individual circulation rule. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 38956] New: Automate MARC Authority Updates with the Library of Congress
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '25

18 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38956 Bug ID: 38956 Summary: Automate MARC Authority Updates with the Library of Congress Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be helpful to pull in regular updates for MARC Authority records rather than manually having to check for updates to subject headings. For example - an author passes away, the current behavior is you need to edit the authority record. It would be beneficial to connect to the LOC database to look for updates automatically. Apis for the LOC https://www.loc.gov/apis/ -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3