[Bug 27160] New: Fatal error when ReservesMaxPickUpDelay is empty and item with hold is checked in
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27160 Bug ID: 27160 Summary: Fatal error when ReservesMaxPickUpDelay is empty and item with hold is checked in Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: dcook@prosentient.com.au QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com If you don't have any value in ReservesMaxPickUpDelay and you try to check in an item that has a hold, you will get an Internal Server Error. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27160 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@bugs.koha-c | |ommunity.org --- Comment #1 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- I don't recreate on master. Please provide more detail if you do. What is the exact error? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27160 --- Comment #2 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #1)
I don't recreate on master. Please provide more detail if you do. What is the exact error?
Oh, I may have not described it correctly. Try deleting the ReservesMaxPickUpDelay system preference completely. That was the actual situation I was facing... As for the exact error, it's one of those Plack errors where you just see "Internal Server Error". It happens when $max_pickup_delay is undef in "$expirationdate->add(days => $max_pickup_delay);" in Koha::Hold I believe. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27160 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|koha-bugs@lists.koha-commun |jonathan.druart@bugs.koha-c |ity.org |ommunity.org --- Comment #3 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- The error is: Validation failed for type named Defined declared in package Specio::Library::Builtins (/usr/share/perl5/Specio/Library/Builtins.pm) at line 44 in sub named (eval) with value undef Trace begun at Specio::Exception->new line 57 Specio::Exception::throw('Specio::Exception', 'message', 'Validation failed for type named Defined declared in package Specio::Library::Builtins (/usr/share/perl5/Specio/Library/Builtins.pm) at line 44 in sub na med (eval) with value undef', 'type', 'Specio::Constraint::Simple=HASH(0x560960117338)', 'value', undef) called at (eval 235) line 75 DateTime::Duration::_check_new_params('days', undef) called at /usr/lib/x86_64-linux-gnu/perl5/5.32/DateTime/Duration.pm line 64 DateTime::Duration::new('DateTime::Duration', 'days', undef) called at /usr/lib/x86_64-linux-gnu/perl5/5.32/DateTime.pm line 1792 DateTime::_duration_object_from_args('DateTime=HASH(0x56096b1fe938)', 'days', undef) called at /usr/lib/x86_64-linux-gnu/perl5/5.32/DateTime.pm line 1764 DateTime::add('DateTime=HASH(0x56096b1fe938)', 'days', undef) called at /kohadevbox/koha/Koha/Hold.pm line 198 Koha::Hold::set_waiting('Koha::Hold=HASH(0x56096b2c4b70)', '') called at /kohadevbox/koha/C4/Reserves.pm line 1189 C4::Reserves::ModReserveAffect(36, 5, undef, 1, '') called at /kohadevbox/koha/circ/returns.pl line 159 eval {...} at /kohadevbox/koha/circ/returns.pl line 2 CGI::Compile::ROOT::kohadevbox_koha_circ_returns_2epl::__ANON__('CGI::Compile=HASH(0x56096894c380)', '', '/kohadevbox/koha/circ/returns.pl', '/kohadevbox/koha/circ', 'ARRAY(0x56096aaa47f8)') called at /usr/share /perl5/CGI/Compile.pm line 151 CGI::Compile::ROOT::kohadevbox_koha_circ_returns_2epl::returns_2epl at /usr/share/perl5/CGI/Emulate/PSGI.pm line 30 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27160 --- Comment #4 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- I don't think we should handle non-existing syspref. In which situation ReservesMaxPickUpDelay got removed entirely from the DB? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27160 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |minor -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27160 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27160 --- Comment #5 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Created attachment 114296 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=114296&action=edit Bug 27160: Prevent 500 when checking an item in if ReservesMaxPickUpDelay has been deleted We could default to 0 if the syspref does not exist. However I don't think we should deal with that kind of issue, sysprefs must be in DB. Test plan: Delete ReservesMaxPickUpDelay from the DB Place an item on hold Check it in Confirm the hold Without this patch you get: "Validation failed for type named Defined declared in package Specio::Library::Builtins" (see the relevant part of the trace at comment 3) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27160 --- Comment #6 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #4)
In which situation ReservesMaxPickUpDelay got removed entirely from the DB?
A library had applied Bug 8367 to a customized production instance. The patches for that bug removed ReservesMaxPickUpDelay. They then exported their database and tried to load it into a new non-customized Koha 19.11.x instance, and that's where they encountered the issue. I will admit that it's an extreme edge case. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27160 --- Comment #7 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #5)
Created attachment 114296 [details] [review] Bug 27160: Prevent 500 when checking an item in if ReservesMaxPickUpDelay has been deleted
We could default to 0 if the syspref does not exist. However I don't think we should deal with that kind of issue, sysprefs must be in DB.
The default in sysprefs.sql is 7, so we might prefer that over 0. I'm not sure that we should deal with this kind of issue either. As you say, sysprefs must be in the database. I'd probably be fine marking this as invalid. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27160 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=8367 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27160 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|Needs Signoff |RESOLVED --- Comment #8 from Owen Leonard <oleonard@myacpl.org> --- (In reply to David Cook from comment #7)
I'd probably be fine marking this as invalid.
I am doing so. -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon@bugs.koha-community.org