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

[Bug 43544] New: update_patrons.pl cron should have a flag for updating the expiration to match the new category
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43544 Bug ID: 43544 Summary: update_patrons.pl cron should have a flag for updating the expiration to match the new category Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Target Milestone: --- There should be an option to update the patron's expiration date to match the new category, similar to how it asks in the UI now. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 26573] New: Limit patron attribute types to more than one patron category
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26573 Bug ID: 26573 Summary: Limit patron attribute types to more than one patron category Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently, Koha doesn't allow to limit a patron attribute type to more than one patron category. Let's say I have a patron attribute type STUDENTID, and I want to limit this attribute to the categories "undergrad students" and "grad students". I have to create two different patron attribute types. To replicate: 1) Go to Administration > Patron attribute types 2) Create a new patron attribute 3) Note that the "Category" field is a dropdown and you can't choose more than one patron category to assign this attribute type to. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 94

[Bug 43710] New: OPAC self-registration crashes with 500 if an attribute type is mandatory+opac_editable but not opac_mandatory
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43710 Bug ID: 43710 Summary: OPAC self-registration crashes with 500 if an attribute type is mandatory+opac_editable but not opac_mandatory Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: adolfo.rodriguez(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- If a patron attribute type is configured with mandatory=1 and opac_editable=1 but opac_mandatory=0, OPAC self-registration crashes with an uncaught-exception 500 instead of completing. Root cause: opac/opac-memberentry.pl's own CheckMandatoryAttributes() only checks the opac_mandatory flag to decide which fields to require on the registration form. But Koha::Patron->extended_attributes()'s internal mandatory check (Koha/Patron.pm, ~line 2884) uses mandatory + opac_editable instead, and ignores opac_mandatory entirely: if ( $interface eq 'opac' ) { $params->{opac_editable} = 1; } my @required_attribute_types = Koha::Patron::Attribute::Types->search( $params, ... )->get_column('code'); So a type with mandatory=1, opac_editable=1, opac_mandatory=0 is never required by the OPAC form, but IS required by extended_attributes()'s own check. If the patron leaves it blank, Koha::Exceptions::Patron::MissingMandatoryExtendedAttribute is thrown at opac/opac-memberentry.pl's call to $patron->extended_attributes($attributes), which is not caught, and the request dies with a 500. By that point the Koha::Patron row has already been created and stored (a few lines earlier); only the extended-attributes save fails, and that save is wrapped in a DBIx::Class txn_do, so the failure rolls back cleanly with no partially-saved attributes. The account itself is valid — only the attribute type configuration is inconsistent. Steps to reproduce: 1. Administration > Patron attribute types: create or edit a type with Mandatory checked, OPAC editable checked, OPAC mandatory NOT checked. 2. With PatronSelfRegistrationVerifyByEmail disabled, register a new patron via the OPAC self-registration form, leaving that attribute blank. 3. The request crashes with an uncaught-exception 500 instead of completing registration. Proposed fix: wrap the $patron->extended_attributes($attributes) call in opac-memberentry.pl in a try/catch. On Koha::Exceptions::Patron::MissingMandatoryExtendedAttribute specifically, log a warning identifying the misconfigured attribute type and let registration complete normally (the account is already valid) instead of crashing. Other exception types are re-thrown unchanged. Note: an earlier internal write-up of this issue assumed the OPAC form and extended_attributes() disagreed on mandatory+opac_editable directly, but current main already guards that combination via the opac_editable filter above — the actual remaining gap is specifically the opac_mandatory vs mandatory+opac_editable mismatch described here. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 37745] New: "Rows per page" not working
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37745 Bug ID: 37745 Summary: "Rows per page" not working Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 34478] Full CSRF protection
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34478 Adolfo Rodríguez Taboada <adolfo.rodriguez(a)xercode.es> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=43709 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41191] New: Multiselect in borrower attributes
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41191 Bug ID: 41191 Summary: Multiselect in borrower attributes 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 I know that it is possible to make a patron attribute repeatable, but I am wondering if it would be possible or beneficial if a patron attribute, if assigned to an authorized value, could it be made so that you could multiselect from that list, like we do with the library limitations, and have those values stored in the field with the separator? This would give us the option of using repeatable fields or having one with multiple choices, and taking up less real estate on the screen if many selections are made/needed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 43708] New: Update subscription add page to use grid layout for forms
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43708 Bug ID: 43708 Summary: Update subscription add page to use grid layout for forms Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Depends on: 39780 Target Milestone: --- - serials/subscription-add.tt Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39780 [Bug 39780] Update library groups form to use grid layout -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 39780] New: Update library groups form to use grid layout
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39780 Bug ID: 39780 Summary: Update library groups form to use grid layout Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 39483 Building on Bug 39483, I'm working to convert the library groups forms to the new grid layout. This will include some changes to the .fg form grid to allow for defining a couple of different widths for the input grid item and to convert the grid-related media queries to be container queries instead. This allows the form grid to be responsive based on width of the the container (<fieldset) rather than the width of the page. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39483 [Bug 39483] Update staff interface forms to use grid layout -- You are receiving this mail because: You are watching all bug changes.

1 58

[Bug 14806] Action Log for Modifying borrower messaging preferences
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14806 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #28 from Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> --- These changes are getting logged when the BorrowersLog system preference is set to "Don't log." Logging should follow the system preference. Not a blocker: When multiple preferences are changed in a single edit, they're making separate entries in the logs per preference. It'd be easier to read in the log viewer if it were one entry that included all edited preferences. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14806] Action Log for Modifying borrower messaging preferences
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '26

02 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14806 --- Comment #27 from Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> --- (In reply to Lari Strand from comment #21) > You need to set up default messaging preferences by patron category in > Modify category in administration-> Patron categories. When you create a new > patron with some defaults set, the stored defaults should show in action > logs. So it's not logging changes to the defaults themselves, but logging when those defaults are applied to a new patron. That makes sense, thanks! -- You are receiving this mail because: You are watching all bug changes.

1 0