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

[Bug 43326] Stored XSS in patron account note (accountlines.note)
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

1 0

[Bug 42916] New: Cannot modify hold expiration date with only place_holds permission
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42916 Bug ID: 42916 Summary: Cannot modify hold expiration date with only place_holds permission Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Target Milestone: --- To recreate: 1/ Create or find a user with place_hold permission but not the top level permission 2/ Place a hold 3/ From reserve/request.pl?biblionumber=X try to edit the expiration date, the date immediately disappears and it not updated I can modify other things like pickup library, suspend, delete, and cancel. This seems to be a change in behavior before 25.11.05 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 47

[Bug 8127] Most-circulated items report doesn't work when limited by library
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8127 David Nind <david(a)davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs documenting |RESOLVED Resolution|--- |FIXED --- Comment #18 from David Nind <david(a)davidnind.com> --- Bug fix, no changes required to the manual (https://koha-community.org/manual/latest/en/html/reports.html#most-circulat…) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41430] New: Retire the patron account flags
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41430 Bug ID: 41430 Summary: Retire the patron account flags Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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(a)bywatersolutions.com It seems odd to have two very specific account flags on patron accounts. We can accomplish the same task with patron restrictions (debarments). I would suggest we retire the patron account flags, and migrate any active flags to restrictions. Furthermore, we could create predefined restrictions, much like we have with predefined notes. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 35337] New: Patron flags should be transitioned over to restrictions
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35337 Bug ID: 35337 Summary: Patron flags should be transitioned over to restrictions 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The existence of patron flags seem arbitrary, like leftovers from before restrictions. It seems like you could accomplish the same thing with just restrictions. I would suggest removal of the flags, and incorporate a Authorized Value that could be customized with preset restrictions, including the former flags. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 35754] New: Place multiple item-group holds at once for the same record
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35754 Bug ID: 35754 Summary: Place multiple item-group holds at once for the same record 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: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com With the availability for item-groups and item group holds it make it very easy for patrons to place a hold on a group of items. This enhancement would provide an option to place multiple item-group holds for the same record. An example use case could be a patron wants to place a hold on volume 4, 5, and 6. Current behavior requires the user to place a hold for vol 4, then place another for vol 5, then finally place a hold for vol 6. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 43553] New: Convert misc/cronjobs/holds/holds_reminder.pl to the Getopt::Long::Descriptive convention (see bug 43546)
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43553 Bug ID: 43553 Summary: Convert misc/cronjobs/holds/holds_reminder.pl to the Getopt::Long::Descriptive convention (see bug 43546) 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: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: jake.deery(a)openfifth.co.uk, robin(a)catalyst.net.nz Depends on: 43546 Target Milestone: --- This is one of a set of bugs filed alongside bug 43546 (Standardize command-line scripts on Getopt::Long::Descriptive) to convert individual, commonly-used cron scripts to whatever declarative option-parsing convention that bug settles on. Depends on 43546. Current state: holds_reminder.pl uses plain Getopt::Long (GetOptions call around line 176). No option is required: --days defaults to 0, meaning all waiting holds, if omitted (around line 195); --library defaults to all branches if omitted; --date defaults to today and is only format-validated if actually supplied; --lettercode defaults to 'HOLD_REMINDER'. What this bug covers: convert the GetOptions call to the new convention purely for consistency and self-documenting --help output, matching bug 43546's convention. No behavior change is expected, since nothing here is actually a missing-required-option bug to fix. Test plan: - --help output covers all documented options and matches current behavior - Running with no options still behaves exactly as before (all branches, all waiting holds, today's date) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43546 [Bug 43546] Standardize command-line scripts on Getopt::Long::Descriptive for safer, more consistent option handling -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 41780] New: Show firstname if preferred_name is empty in moremember.tt
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41780 Bug ID: 41780 Summary: Show firstname if preferred_name is empty in moremember.tt Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: ayoub.glizi-vicioso(a)inLibro.com Reporter: ayoub.glizi-vicioso(a)inLibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Depends on: 28633 Since bz28633, the patron's firstname is no longer displayed in the staff interface (moremember.tt) if the 'preferred_name' field is NULL or empty. This issue occurs when patrons are imported via external scripts (like Activitek) that do not automatically populate 'preferred_name' with the 'firstname' value. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28633 [Bug 28633] Add a preferred name field to patrons -- You are receiving this mail because: You are watching all bug changes.

1 83

[Bug 40157] New: OAI's CSS should be updated to Bootstrap 5
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40157 Bug ID: 40157 Summary: OAI's CSS should be updated to Bootstrap 5 Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The current files are dated (bootstrap 3) and contain http links to fonts which cause the OAI page to be displayed as insecure. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 43072] New: Hold policies display incorrectly in circ rules page
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43072 Bug ID: 43072 Summary: Hold policies display incorrectly in circ rules page Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests 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, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Depends on: 41267 Target Milestone: --- Bug 41267 added a new hold policy type to the "Default holds and bookings policies by item type" section at the bottom of the page, "Fill other record level holds on record at checkout." If this policy is set to Yes or undefined, an item of the given itemtype can fill a bib-level hold even if the itemtype doesn't otherwise allow holds. If the policy is set to No, then the itemtype will not fill record-level holds. On upgrade, Bug 41267 does not set anything in the circulation_rules for this policy. After upgrade, any itemtype that has a value set for something else in this section will show a value of "No" for "Fill other record level holds on record at checkout" even though this policy isn't actually set. So the upgrade doesn't actually change any circ behavior, but it shows an erroneous change in the circ rules. To recreate: - be on a version of Koha without this code (25.11.04 or older) - set Hold Policy = "No holds allowed" for an itemtype - upgrade Koha to a version with this code - reload the circ rules page, confirm the Default holds and bookings policies by item type section still shows your Hold Policy value and *also* shows "Fill other record level holds on record at checkout" set to "No" for your itemtype - query "select * from circulation_rules where rule_name='fill_other_biblio_holds_policy'" and confirm no rule exists in the database - confirm a record-level hold can still be filled with an item of your itemtype - update your circ rules to actually save a No for "fill other record level holds" - confirm this now shows in your circ rules query - confirm a hold no longer fills It seems simplest to make this table show "Yes" when no policy exists. But on the other hand in current main I cannot set any rule in this table without also setting a "Fill other record level holds" value, so maybe it would be more consisten to actually save a "Yes" rule for 'fill_other_biblio_holds_policy' on any itemtype that already has something set for any other rule here. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41267 [Bug 41267] It should be possible to prevent some itemtypes from filling other biblio level holds -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 36