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

[Bug 34064] New: Compare kohastructure.sql against current database using database audit script
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '25

20 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34064 Bug ID: 34064 Summary: Compare kohastructure.sql against current database using database audit script 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz As Marcel notes in bug 30486, it's common for an upgraded database to be inconsistent with kohastructure.sql. It would be useful to have an audit script which could compare the current database with kohastructure.sql to see what differences there are. -- Fortunately, I've come up with a script, which hopefully should get us most of the way there. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 53

[Bug 41278] New: Make audit_database.pl skip koha_plugin_* tables
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '25

20 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41278 Bug ID: 41278 Summary: Make audit_database.pl skip koha_plugin_* tables Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz If a Koha database has tables created by plugins, misc/maintenance/audit_database.pl will output recommendations for altering and deleting these tables. Although there is a caution about the ouput only being recommendations, it seems just skipping tables that have names beginning with koha_plugin_ might be a good idea. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 8137] Checkout limit for all libraries
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '25

20 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8137 --- Comment #157 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Bug 27834 is changing code in TooMany. So very related. Just noting that while I was testing some global and branch level rules on current master, I found that I could loan more books in one order of checkouts than in another order. Which is governed by TooMany. Is that really what we want to happen? Dont think so. The current algorithm seems to be too complex. I am not sure if we should 'fix' that by adding more columns or so? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8137] Checkout limit for all libraries
by bugzilla-daemon＠bugs.koha-community.org 20 Nov '25

20 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8137 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy(a)rijksmuseum.nl -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33182] New: Expand options for OpacItemLocation
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '25

19 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33182 Bug ID: 33182 Summary: Expand options for OpacItemLocation 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The options in OpacItemLocation are: -library and call number -library, collection code, and call number -only libray -library, location, and call number These options seem a bit arbitrary. I often have requests to have both collection code and location but that is not possible with the current configuration. -- You are receiving this mail because: You are watching all bug changes.

1 8

[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