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: [email protected]
Reporter: [email protected]
QA Contact: [email protected]
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.
_______________________________________________
Koha-bugs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
